On 27 Jul 2009, at 10:55PM, Stephan Assmus wrote:
Hi Chris, On 2009-07-27 at 23:41:18 [+0200], Chris Peel <chris.gsi@xxxxxxxxxxxx> wrote:Is there a way the devs (I'm guessing Axel, yourself, etc.) could assignsome form of 'likelihood' rating against each item? For example, I'm guessing adding WLAN support might be 90% achievable while "New File System" might be much harder and therefore only 20% achievable (badexamples, I know). Maybe the dev(s) who's most likely to tackle the newfeature could add the rating and it could be adjusted over time. This would then give (a) the request submitter and (b) lurkers like myself a view on how likely their request is going to appear in which release. Just a thought - it might be too onerous to maintain.Ah ok, this was perhaps not very clear. With the "unscheduled" list, it was like "we definitely want these", or in another words "100% likelyhood", but we have no idea when anyone will get around to implementing them. So the basic idea was that we could make point releases after R1 wheneever one or more of these features from the unscheduled list would become available.Having a rating or even voting system to stress the importance of somefeature over another would not make it appear sooner. It would just give a false impression and/or make promises we are unlikely to be able to keep.
No, sorry, I didn't make myself clear. I didn't mean the rating system would be based on the importance of a particular feature (they'd all be 100% in that case); I meant it as in 'how easy/ difficult to implement' - it would be the dev implementing the feature who would assign the rating, not the requester. In many cases there would be no-one available/able to undertake the request, in which case the rating would simply be 'n/a' or blank.
Best regards, -Stephan