Propagating Forum discussions to "decision-makers"

[Gale Andrews]

From: http://forum.audacityteam.org/viewtopic ... 68#p107556

The Development Team generally does not read this forum, rarely looks at the wiki, and with a few exceptions do not read the Quality mailing list. That seems to leave only the -devel mailing list but the Developers get very antsy when people are who do not have "commit rights" encourage this kind of discussion on that list.

You cannot expect developers (==programmers) to read the Forum. I personally do expect them to use the Wiki, though some are reluctant. Where I fit in is odd; you could argue I am in a broader "Development Team" but obviously I am not a C++ programmer, and I think this applies to a lesser extent to Steve, Peter and the other "elves". Likewise, my main duties lie outside the Forum so I simply cannot contribute to it with the same volume of posts as the other elves (or read it all).

What I think matters most is a process for getting discussions from the Forum back to the broader "Development Team" which includes the "programmers". At the moment the main way is via the -quality list with the reservations you note, or to pull my ear by pointing me to these Forum discussions so we can decide if bugs need to be raised or discussed with developers first.

I can't do anything about "antsy developers" - I think that problem is fundamentally the reason the -quality list was set up which I regret for many practical reasons, though it does provide a flawed vehicle for reaching some of the developers and helps to "keep the peace". I think there could be some antsiness even there if it was used more heavily or threads got too extended.

Is there any way propagation out of the Forum can be improved within these constraints?



Gale

[waxcylinder]

I can offer no real solution - but I would like to highlight two of the problem areas:

======================================================

I was concerned to read on the mailing lists this week that Vaughan had very poor visibility of changes in the Wiki (You and I Gale gave him some suggestions for easier monitoring). And if Vaughan is not reading the Wiki it is extremely likely that many of the other developers are not either. I had always worked on the understanding that the Wiki was one of the primary ways of communicating with the developers (less intrusive than using the devel mailing list - as it is a pull rather than a push technology - and does not bombard them with email that they clearly do not relish). In particular I assumed that the "Proposal ..." pages and the "Feature Requests" page were key reading for the developers. Is this not the case?

=====================================================

As part of my elf duties involve managing part of the feature request process, I am acutely aware of the slowness of the process.
For those who don't know, the workflow is:
1) Posters make a suggestion thread in the "Adding Feature to Audacity" section of the forum
2) other posters add comments/suggestions/votes
3) once the thread has been dormant/inactive for one month it is transferred (by me) to the "Pending Feature Requests" page in the Audacity Wiki.
4) Gale then triages the items on that page and, if suitable, transfers them and any votes to the Feature Requests page in the Wiki
5) Developers read the FR page and choose new features to implement ???

The flaws in this process:
a) Step 4 is (rightly) a low priority task for Gale - he has much other Audacity work to do which takes priority - so items can and do stay on that page for a long time.
b) I'm not sure that step 5 takes place at all (and certainly not in any managed or organized way). Please correct me Gale if I am wrong about this.

=======================================================================

WC

[Gale Andrews]

I assumed that the "Proposal ..." pages and the "Feature Requests" page were key reading for the developers. Is this not the case?

I think it's not the case. You would have to keep dropping links to the proposals into your e-mails as a reminder.

As part of my elf duties involve managing part of the feature request process, I am acutely aware of the slowness of the process.
For those who don't know, the workflow is:
1) Posters make a suggestion thread in the "Adding Feature to Audacity" section of the forum
2) other posters add comments/suggestions/votes
3) once the thread has been dormant/inactive for one month it is transferred (by me) to the "Pending Feature Requests" page in the Audacity Wiki.
4) Gale then triages the items on that page and, if suitable, transfers them and any votes to the Feature Requests page in the Wiki
5) Developers read the FR page and choose new features to implement ???

The flaws in this process:
a) Step 4 is (rightly) a low priority task for Gale - he has much other Audacity work to do which takes priority - so items can and do stay on that page for a long time.
b) I'm not sure that step 5 takes place at all (and certainly not in any managed or organized way). Please correct me Gale if I am wrong about this.

I don't think Step 5) really takes place at all at the moment given we're in bug-fix mode. Some developers are fairly aware of the Feature Requests page and others hardly at all. Apart from people who start Proposals needing to be aware of and point to relevant Feature Requests, I think the FR's are mainly an "investment for the future" at present, but it's worth keeping up with the job.

But where something that could be a bug is discovered in discussing an FR, that should definitely be propagated, straight to Bugzilla if it's obviously a bug, otherwise by asking me or posting to -quality.

Sometimes it's possible to "sneak" small enhancement requests into an actual bug fix if they are relevant to it (a supplied patch might help here); or sometimes if enough of us like the idea of an enhancement it could go on Bugzilla as an enhancement issue (votes for it should still be counted on the FR page, of course) . Usually putting an enhancement issue in Bugzilla would have to be discussed on -quality but it depends... I may feel it's relevant enough to existing bugs to put it straight on Bugzilla.



Gale