If you look at the “About this Community” section you will find a links to forms for submitting new features and voting for other feature suggestions.Â
Fabrice Fournier Its ok to keep the section, because just like bugs, people may think that a feature needs to be added, when in fact its already there and they just dont know how to do it.Â
I think, no need for that category. As Bill Surowiecki said, the feature you want maybe already there. So I think asking first before submitting will be the thing to do.
Jhonbert Magana Many people don’t see the links in the “About this community” .rather than having everything in the discussion section why just store properly the news?
If I had not told some of  post their screen in dedicated session we will quickly invaded ….. right? 😉
I think the first thing to do is to establish the current list of “official” and current features request, and publish it somewhere here (in the “About this community”). I am working on it at the moment, and I hope to finish it soon (in a few hours).
Then the section to discuss about features is a good place to refine requests, exchange about ideas, and so on.
And finally the form that Bill Surowiecki created is a great tool to ensure that feature requests are not lost in the discussion and track them: once a request is clear, we can fill the form, and all is left to do is to check for duplicate and update the final TODO list… and code !
I think this is fine this way: features goes through the form after discussion, are stored in the associated spreadsheet (internal use, not public), and are gathered and cleaned up, if needed, in the TODO list (public, view only).
We can follow the exact same route for bugs, but bugs and features need to be in distinct lists though. Does it sound goods ?
(I am going to bed now, so don’t expect replies from me before a while…)
< ![CDATA[
I can create a suggestions or TODO or request section 🙂
]]>
< ![CDATA[
i created the section 😉
]]>
< ![CDATA[
Thanks!
]]>
< ![CDATA[
No prob it’s a pleasure 😉
]]>
< ![CDATA[
Fabrice Fournier Grace-Ann CurbyÂ
If you look at the “About this Community” section you will find a links to forms for submitting new features and voting for other feature suggestions.Â
]]>
< ![CDATA[
ok i see i delete this section srry 🙂
]]>
< ![CDATA[
Fabrice Fournier Its ok to keep the section, because just like bugs, people may think that a feature needs to be added, when in fact its already there and they just dont know how to do it.Â
]]>
< ![CDATA[
lol ok 🙂
]]>
< ![CDATA[
Bill Surowiecki i deleted it if u want create the new 😉
]]>
< ![CDATA[
I think, no need for that category. As Bill Surowiecki said, the feature you want maybe already there. So I think asking first before submitting will be the thing to do.
]]>
< ![CDATA[
Jhonbert Magana Many people don’t see the links in the “About this community” .rather than having everything in the discussion section why just store properly the news?
If I had not told some of  post their screen in dedicated session we will quickly invaded ….. right? 😉
]]>
< ![CDATA[
I think the first thing to do is to establish the current list of “official” and current features request, and publish it somewhere here (in the “About this community”). I am working on it at the moment, and I hope to finish it soon (in a few hours).
Then the section to discuss about features is a good place to refine requests, exchange about ideas, and so on.
And finally the form that Bill Surowiecki created is a great tool to ensure that feature requests are not lost in the discussion and track them: once a request is clear, we can fill the form, and all is left to do is to check for duplicate and update the final TODO list… and code !
What is your opinion about this ?
]]>
< ![CDATA[
it’s exactely what i think a section request suggestion and when you have refine the questions in Bill Surowiecki form .
]]>
< ![CDATA[
I also think that if the feature request form is available to everyone …. there will be dozens of unnecessary queries to sort …. while sorting the requests in the dedicated section can then send the form that would be accessible only to a few competent people. Pierre Hébert Bill SurowieckiÂ
]]>
< ![CDATA[
Ok, the TODO list is now in the about panel 🙂
]]>
< ![CDATA[
thks Pierre HébertÂ
]]>
< ![CDATA[
I just updated the panel as well Pierre Hébert I added a form (not public) that feeds into a publicly viewable spreadsheet for known bugs. It contains fields for bug description, submission date, working on it (yes/no), should be fixed in next release (yes/no), and next release version number.Â
]]>
< ![CDATA[
Pierre Hébert Just updated the Community Etiquette form with your todo list, deleted mine.Â
]]>
< ![CDATA[
Thanks Bill Surowiecki , the visibility over what bugs are being processed is a good idea to help people know that a fix is coming.
]]>
< ![CDATA[
Pierre Hébert Well do you want to add it to your list, or should I recreate the spreadsheet again.Â
]]>
< ![CDATA[
I think this is fine this way: features goes through the form after discussion, are stored in the associated spreadsheet (internal use, not public), and are gathered and cleaned up, if needed, in the TODO list (public, view only).
We can follow the exact same route for bugs, but bugs and features need to be in distinct lists though. Does it sound goods ?
(I am going to bed now, so don’t expect replies from me before a while…)
]]>