stack overflow

tom1 · 2012-11-14 18:03:29

hey community! I’ve been crawling thru these forums various times for information on plugins, and such.
The problem i come up with most of these times is 20+ pages long threads, with some vital information spread on all or some of the pages.

I’m quite new to Stack Overflow, but i see greatness in its functionality and was wondering if there would be any idea to maybe use it alongside these forums?

any thoughts?

edit: Oh did i fail to mention i was thinking of this speacially with plugin-help threads.

Last edited by tom1 (2012-11-14 18:05:35)

mrdale · 2012-11-14 18:18:50

Are you thinking of voting-based sorting of topics?

tom1 · 2012-11-14 18:25:04

I think the magic is in the topic-per-question logic. Now if i have a issue with txp plugin, i might have to crawl thru 20+ pages to find if someones been talking about it ( ofcourse i can use search but it dosent gurantee results ). I feel that theres less jargon on SO, and more of results. This probably because of voting mechanism, users want to keep their answers clean

mrdale · 2012-11-14 19:33:40

Here’s the problem. Most questions on Stack Overflow are very specific, whereas the function of the plugin support forum is that of a collection of questions and answers (plural) for a particular plugin (which may have many functions and usages.

I don’t see the two being compatible. :(

Bloke · 2012-11-14 20:28:30

If you are thinking of doing this kind of thing, please consider raising your hand with the .org redesign. It’s been too long laying dormant and I’ve pledged to start fixing that pronto.

On Destry’s prompting, one of the things I’m keen to explore is the notion of curated content. So instead of rambling 50+ page threads, each plugin has (say) a wiki page on textpattern.net. Right there is important content that has been plucked from the belly of the forums, or put there by the developer / community as being important.

It could be stuff like “to make this (unsupported) plugin work on 4.x.x, do this and this”. Or it could be known issues to save people posting a bug report. Or planned features. Basically, it can be anything that’s relevant and current for the most recent version of the plugin. As the plugin and/or Txp move forward, it’s up to the community to weed out the old / irrelevant stuff and put in new content to keep the page fresh and up-to-date. Thus the plugins that are most used, or used by a specific segment of the user base get fresher content. As important things come to light in the forums, they can be transferred to the wiki page, perhaps replacing some outdated info that was there.

Most importantly, the wiki archives all changes and can create diffs so info is never “lost” as such. if you want to dive into the past and find something, you can. But the idea is that you won’t need to because everything current and relevant about the plugin is in one page. The page length of a wiki page is limited too, so that forces the content to be kept up to date.

Of course the forum stays open. As do other social channels. If the developer wants a report to be filed on a Git/Mercurial Issue tracker, or a Facebook page(!), so be it. These choices are up to the individual developer and the .org site is the jumpoff point that drags all the relevant info into one nicely presented place where people can find everything about the various plugins on offer, download them, find about issues, future plans, donate to the author/project, blah blah.

Please consider jumping in and dropping me a mail. I could do with the hands to motivate myself to tackle it.

Oh, and back on topic. Stack Overflow is all well and good, but the number of times I’ve actually found anything relevant is small. Most of the time it’s a bunch of egotistical jerks arguing over why the OP hasn’t asked the question better or hasn’t found the other 5 obscure, barely-related topics of the same type, or bashing each other over why their version of code is better despite it being the 5th vote down the list. Or locking topics because they don’t like the answers. Childish behaviour, imo. If I want to be insulted by people I’ll go and post a badly spelled comment about Justin Bieber on YouTube or hang out with the trolls on IMDB.

Last edited by Bloke (2012-11-14 20:33:57)

Destry · 2012-11-29 11:36:51

Stef,

Drop me a line anytime to remind me what I can do on the wiki side to facilitate the linking between .org and .net for plugins.

I guess for starters I could create a wiki category for those pages? That would probably sit nicely as a landing page under the Plugins section on the home page.

From there a page title convention would probably be useful, like “{plugin name} docs”, e.g., smd macro docs. We should probably follow the tag references convention where the underscores are dropped and the first letter is kept lowercase reflecting the actual prefix convention. So the global constant there would be “docs”, and then a per dev constant would be the prefix (e.g., “smd”), and then the plugin identifier would change individually.

I could look into how a wiki template (or multiple nested) might be used to facilitate creation of each docs page. I’d guess not all docs would require the same doc structure (page sections), but we could start with a real basic foundation, maybe, based on whatever it is for plugin docs currently. I’d have to look somewhere.

Other ideas to explore that can help you?

Bloke · 2012-11-29 12:00:34

Destry wrote:

I guess for starters I could create a wiki category for those pages? That would probably sit nicely as a landing page under the Plugins section on the home page.

That would be great, thanks. Been discussing ways to do this (offline) with tom1. I’m of the opinion that it makes sense to have one page per plugin but there’s an argument for having one per (major) version so there’s a history of changes and also it means people can still get support for older versions (for whatever reason). But it’s more complicated to manage and might get bogged down in cruft so I’m not sure if it’s worth it.

Templates would be fab. The one for the tag pages works well. Just a skeleton doc for page creation, but we’d have to figure how people would add curated content and keep things sane. Convention is good, as long as everyone knows the convention :-)

Destry · 2012-11-29 13:10:26

Bloke wrote:

I’m of the opinion that it makes sense to have one page per plugin but there’s an argument for having one per (major) version so there’s a history of changes and also it means people can still get support for older versions (for whatever reason). But it’s more complicated to manage and might get bogged down in cruft so I’m not sure if it’s worth it.

I agree that it should be one wiki page per plugin.

One of the fundamental problems with poor user documentation is not knowing what one should actually be looking at. Multiple pages isn’t solving the problem; all that’s doing is taking a linear forum thread and laying it out horizontally in the wiki. Maybe you organize the thread content better by chopping the snake up and moving the pieces around to the related version context, but it’s more to manage and process on the one hand, and still just as confusing to the user on the other. All they want is the latest working info.

So, this is easily addressed by remembering who the audiences are and what they need, respectively. The wiki is the end-user manual. Plugin docs are for end-users of the plugins. End users are generally going to be users of the current stable release of Txp. In fact, a core recommendation for security reasons is to update the Txp install to the lastest stable release. The lastest stable release is the context for user docs. I don’t see how that ‘message’ should be any different for plugins. In which case, when a plugin evolves, it’s non-supported in code and documentation.

If developers want their own code history docs, then that sounds like something different for .org, or Github. Maybe that’s what you do in .org; for each plugin profile you provide for a Github link where devs keep old history cruft, if they want to.

If not something in .org/Github, then just continue to use the forum for loose banter about past versions and their associated issues. That’s a concern for plugin devs to address in discussion, I would think.

Bloke · 2012-11-29 16:36:44

Destry wrote:

The lastest stable release is the context for user docs.

I concur. One page per plugin is fine by me. Simple, focused, time-bound and accurate.

Textpattern CMS

Textpattern CMS support forum

#1 2012-11-14 18:03:29

stack overflow

#2 2012-11-14 18:18:50

Re: stack overflow

#3 2012-11-14 18:25:04

Re: stack overflow

#4 2012-11-14 19:33:40

Re: stack overflow

#5 2012-11-14 20:28:30

Re: stack overflow

#6 2012-11-29 11:36:51

Re: stack overflow

#7 2012-11-29 12:00:34

Re: stack overflow

#8 2012-11-29 13:10:26

Re: stack overflow

#9 2012-11-29 16:36:44

Re: stack overflow

Board footer