Hrm. My last reply doesn't seem to have been posted. :(. I'll paraphrase...
> > There is a difference between seeing the need for a something and > > prioritizing the work for it. Seeing the need is where this discussion > > started and hopefully you agree that FireBug's documentation needs > > some polish. Once the need is identified, the work can be done by via > > user contributions or by the FireBug team. With no clear and simple > > platform for user contributions (e.g. no Wiki, no user authored forum > > stickies, etc), this means the FireBug team must prioritize this work > > item among all other items. > > If you would like to volunteer to monitor the Wiki, remove the sex ads > and ban the posters of same, then I would happy to re-enable to the > wiki pages. I turned them off because the cost/benefit was too high. The cost/benefit is a concern regardless, but you could cut down the amount of SPAM that got published by requiring new users to get their contributions approved before they are published. After several non- SPAM contributions are approved, you upgrade them to allow publishing without approval. > > TBH it's not that the information isn't available, it's that the > > information is scattered all over the place; it's in FireBug Google > > Group replies, FireBug Working Group pages, disconnected > > getfirebug.com web pages, and various blogs. So if the information is > > already available (meaning the hard work of capturing the knowledge is > > already done), you only need to do a smattering of additional work to > > create a codex of links to that knowledge. > > Sincehttp://getfirebug.com/docs.html > > already has 6 reference links like this, you could easily flesh out > > those links with more. It's near zero work for the FireBug team to > > maintain such a codex and it doesn't change the way or amount of > > documentation that the team is already doing on their own (e.g. via > > blog posts), but this would be a tremendous help to users, especially > > new/novice users. > > If you would like to contribute this near zero work, you please let us > know. > > Honestly I have no idea what mechanism works for users to learn about > Firebug. I don't know why they use the docs.html page rather than the > "learn-more" links...or whether they do. I don't know if they read our > blog posts or not. Unfortunately your experience may not be similar to > other users (even if you think it is). I've spent a lot of time on > documentation, so your feedback basically tells me I should not > bother. > > I think rather than a broadcast mechanism to an uncertain audience, > building info about updates in to the UI makes more sense. If the front page and the Learn More links are supposed to be the main documentation, then why does the FireBug Online -> Documentation menu item take you to http://.../docs.html? And this example demonstrates what I see as the big issue: it's not that there are no docs, it's that they are scattered and buried. IMHO, the solution requires almost no work by the FireBug team. Simply use the front page and Learn More pages as your sales pitch only and upgrade http://.../docs.html to be a full codex of FireBug knowledge. Instead of writing custom pages for http://.../docs.html, link to the already existing information. Not only does this allow you to continue using your current communication methods (e.g. blogs, forum posts, etc), but it allows you to link to user generated information on other sites (with an appropriate warning footnote, of course). If you think the FireBug team can't handle this, ask for user community input on what links belong there. -Foam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
