Twitch Documentation on StackOverflow

API
1

Hey, devs!

We are a launch partner for StackOverflow’s Documentation product! We thought it would be a cool way for our community to have a centralized place for common questions and answers. We seeded a couple of topics and would love contributions or updates! Check it out and please do contribute!

Twitch on StackOverflow

-D

3 Likes
2

As I mentioned in the Irc, PLEASE:

  1. Keep the github documentation for endpoint information. Explain usages, example request/response data, etc there
  2. Use stack overflow ONLY for implementation questions / expanding on github api information for language specific contexts

Github is WAY better for document centralization and information dissemination. Stack overflow (Even the document stuff) is WAY better for Q&A, historical retention and visibility [of questions], along with upvotes for good working solutions.

Please keep these two concepts clear cut and separate, otherwise twitch api documentation is going to be a nightmare to read.

2 Likes
3

We’re not moving our documentation wholesale to SO Documentation. It’s a place for one-offs, language-specific examples, and a place for the community to build their own samples. We have other plans for our documentation that I’ll share at a later date.

1 Like
4

We should also make sure that if parts of the undocumented API are “documented” on SO that it’s clearly marked as such. Otherwise it might mislead people into thinking that they are using a stable part of the API, when in fact they are not.

1 Like
5

Expanding on this, I would love if we could have some type of system to upvote including unofficial api endpoints as official kraken endpoints.(actual kraken url)

I’m looking at you, /chatters.

6

100% agree, @Qntm. We’ll have to be diligent in making sure we annotate the code that has unsupported APIs.

I’m looking into how we could use GitHub Issues for API requests and bug reports, @tournymasterbotCurse. Right now, it’s a mishmash of questions, requests, bug reports, and other miscellany. The other side of that is making sure the product teams have visibility into the requests. Inconsistent right now for sure.

7

The big thing is just defining where things are, and what they are for.

  • Github: API Documentation, Error reports (API down, returning invalid results, etc)
  • Forums: API/Chat/Whatever discussion, talk about things you’d like to see, etc etc. Something that requires back and forth
  • Stack overflow: implementation specifics, generally language specific, multiple examples for any given endpoint, etc.

The problem arises when you move something that is extremely well suited for a platform (IE: high level api calls, non language specific that shows the request json/response json from github to stack overflow = bad)

Having stack overflow have examples for /streams using ‘Javascript’, ‘Jquery’, ‘PHP’, ‘C#’, ‘Ruby’, ‘Python’ … is great - and exactly what a good implementation of the stack overflow docs is perfect for.

That way the github can have example request/response json, and ‘See language specific examples at [stack overflow link]’

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.