> > 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.
Yes, cost/benefit is always an issue for free projects. However, if you want to give it a shot, you could simply use a Wiki that required new users' submissions to be approved; i.e. only after X number of posts have been approved would that account be allowed to make unapproved posts. This limits your exposure to SPAM while still letting the truly active users maintain the Wiki. > > 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 you expect the front page and Learn More links to be the main documentation, then why does the Firebug Online -> Documentation menu item point to http://.../docs.html? When talking about documenting a project, I think there are four areas to cover: 1) A place where people who aren't already using your product can learn about it. This is where the sexy sales pitch stuff goes. It tends to be light on details and use lots of pictures and testimonials. IMHO this is what the main page and the Learn More pages are for. 2) A user's guide that outlines how to do use the project to do things. FireBug is pretty straightforward so you don't need much of this, but there are a few posts here and there that have this kind of information (e.g. the Net panel explanation at http://www.softwareishard.com/blog/firebug/introduction-to-firebug-net-panel/). Also, this is where the details about the Activation Model should go. 3) A reference guide that contains all of the nitty gritty details and reference tables. This is where advanced users dig into advanced usages and also where all users get a summary of things; e.g. options, keyboard shortcuts, API info, etc. This is basically what the current http://.../docs.html is. 4) Anything not covered above requires specific user support. This starts with static information like a FAQ and forum stickies, but requires some kind of discussion framework. FireBug has a FAQ and Google Groups handles the direct user discussions. So from my point of view, things are a bit jumbled, but you aren't that far from having things nailed down. Per #1, keep the front page and Learn More as the sales pitch only. Because #2 will be so short, combine #2 and #3 into a single reference; either a Wiki or at http://.../docs.html. Assuming you don't do a Wiki, instead of reproducing materials specifically for http://.../docs.html, simply use links to blogs and other key articles. If you don't think the FireBug Team can handle updating http://.../docs.html, then why not make a general call to the community for a list of what they want reflected here and then ask for a user draft with the accepted information? Many users, myself included, wouldn't mind helping but don't know all of the information/links required. Regards, -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 -~----------~----~----~----~------~----~------~--~---
