Community contributed docs/examples from StackOverflow

[zoltan]

Hey all,

I have some exciting news to share. The StackOverflow team are working on a new product that’s going to take the community moderation/contribution model that they’ve so successfully mastered with SO and apply it to documentation. It will (at least initially) be ideal for sharing code examples to get particular things done. These will be tied to specific versions of Meteor and in true SO style the most popular/highest quality will become the most prominent.

The folks at StackOverflow have reached out to see if Meteor would participate as one of the frameworks showcased in their launch coming up soon.

Unfortunately I can’t give away too many details pre-launch but I wanted to share our excitement and give the community a heads up that this is coming.

[sashko]

I’d be interested in hearing how people think this might interact with existing community wikis, cookbooks, and the like - it could be a great place to share one-off snippets or articles about how to do stuff.

[tmeasday]

Yeah, especially @awatson1978 and @gadicc – would you see it as an advantage to have a central, Stack-overflow branded location to find and link to this sort of content (with let’s assume all the things that SO is good at, significantly SEO), or do you think it would detract from the existing situation with Meteorpedia and the Clinical Meteor cookbook?

[reoh]

This sounds awesome! It’s really cool that Meteor will be involved initially… excited to see how it works out.

[awatson1978]

would you see it as an advantage to have a central, Stack-overflow branded location to find and link to this sort of content (with let’s assume all the things that SO is good at, significantly SEO), or do you think it would detract from the existing situation with Meteorpedia and the Clinical Meteor cookbook?

Generally speaking, the StackOverflow solution seems like a good opportunity to shift some of the Cookbook’s maintenance burden to a crowdsourced model. I’ve been cannibalizing the Cookbook for some time now, moving content into packages and slimming things down where possible. So no worries about detracting from what’s currently happening with the Cookbook.

Between the Guide and StackOverflow, I’d be likely to drop all of the general recipes; and double-down on healthcare recipes like how to graph ECG signals or load DICOM images, which probably won’t wind up on StackOverflow. That’s the stuff I really want to be working on anyway.

Also, the Cookbook has definitely been heading towards being a framework, ala Mantra. (I’d even suggest that Clinical was doing the framework thing first, and Mantra only has half as many stars as Clinical. ) I’ve already been experimenting with rebranding it (it’s now under the clinical-meteor organization, for example); and it may very well wind up repositioned as an healthcare specific SDK (focusing on examples, package tracking, and a tutorial).

My concerns with the StackOverflow solution are with things like categorization, who is defining best-practices, the ‘voice’ of the documentation, fragmentation, competing advice, etc. A lot of the recipes in the Cookbook are organized according to theme and aimed at intermediate users who use Blaze and traditional Javascript. So I’d like to see how similarly related topics get handled. (But I can only imagine that a database driven solution would be better than flat text files.)

If that jQuery Documentation page is an example of a dashboard that anybody could fire up, I’d be quite likely to migrate a huge chunk of the Cookbook over.

Like… is jQuery Documentation a dynamic tag? Or a topic page that an individual or organization can control and say is their own? Is this truly crowdsourced? Or can an individual or team maintain some amount of editorial control of what gets published? Can we filter/sort by language what examples go into the documentation (i.e. enforce coffeescript/javascript/ecma)? What if we only want particular libraries in the documentation (d3/mongo/blaze/nightwatch)? How is documentation versioned and different flavors handled (d3/mongo/react/gagarin)?

But generally speaking, if this is a solution I could offload generic recipes to, I’d be fine with slimming down the Cookbook and seeding the site for the community. That would let me rename the cookbook repository to clinical-sdk and focus more on healthcare, which is it’s next evolution, I think.

[tmeasday]

Like… is jQuery Documentation a dynamic tag? Or a topic page that an individual or organization can control and say is their own? Is this truly crowdsourced? Or can an individual or team maintain some amount of editorial control of what gets published? Can we filter/sort by language what examples go into the documentation (i.e. enforce coffeescript/javascript/ecma)? What if we only want particular libraries in the documentation (d3/mongo/blaze/nightwatch)? How is documentation versioned and different flavors handled (d3/mongo/react/gagarin)?

I don’t think we really know the answers to these questions yet but we’ll probably find out pretty soon!

But generally speaking, if this is a solution I could offload generic recipes to, I’d be fine with slimming down the Cookbook and seeding the site for the community. That would let me rename the cookbook repository to clinical-sdk and focus more on healthcare, which is it’s next evolution, I think

Sounds like a win-win then!

[tmeasday]

Let’s make sure we get the “Meteor Cookbook” articles in this: https://github.com/meteor/guide/issues/13

[zoltan]

StackOverflow solution seems like a good opportunity to shift some of the Cookbook’s maintenance burden to a crowdsourced model

This appeals greatly to us for Meteor too!

[gadicc]

would you see it as an advantage to have a central, Stack-overflow branded location to find and link to this sort of content (with let’s assume all the things that SO is good at, significantly SEO), or do you think it would detract from the existing situation with Meteorpedia and the Clinical Meteor cookbook?

I think we won’t know until we try On the whole it sounds great and I’m very keen to see how it works out.

Personally, I’ll always prefer a wiki approach, where multiple contributors work together to keep a single source of truth up-to-date (for this reason, I’m loving the guide with community contributions). I don’t feel that Meteorpedia lived up to my expectations in this regard; I think people generally prefer publishing under their own name and getting either hits on their blogs or likes on the forum.

I think that points and rankings is a great motivating factor, that SO is an established brand, and ultimately, that whatever method leads to the best, clearest and easiest to find docs for the community is the best solution.

[loren]

I prefer the Sashko&Tom-deciding-what’s-best model over the SO upvote model So I wouldn’t want to see the Guide migrated to SO Docs (maybe could link from eg the SO “Authorization How-to” Doc to the Guide section that talks about roles, and that link would get the most upvotes). But since S&T can only write / merge / maintain so much, need to figure out the line between what you make a Guide article and what you send to SO – probably some measure of how common the topic comes up for devs. For example I’d say file uploading and robust logging are commonly-needed enough to go in Guide, and the D3 Visualizations Cookbook should go in SO Docs.

I’m not sure how the SO Docs UI will look, but from an information-organizing and discovery perspective, I’m guessing it would be helpful to have sections of the Guide that just linked to different SO Docs, like in the Views article, have a list of links of other view topics: "Meteor + D3 (graphs / data visualization) " SO Doc, “Meteor + Ionic (mobile UI framework)” SO Doc, etc. And the time/effort to curate which is the best way to do D3 Visualization is offloaded from S&T to the not-as-omniscient-and-sometimes-out-of-date SO upvoting community

[sashko]

So I wouldn’t want to see the Guide migrated to SO Docs

Yep - not part of the plan currently. We think this will be a great supplement for the topics we don’t cover, and I think the questions you’re talking about are exactly the right ones.