[development] Voting on issues (was Re: How to post bug reports andpatches)

[Ashraf Amayreh]

I kind of remember the solution in priority queues, the problem was
starvation, when an issue just keeps being pushed back indefinitely.

Adding age of issue creation as a factor in the issue exposure should
make sure this problem doesn't happen. After some time even the most
uninteresting issue will eventually float above all others because
it's been there for long.

On Sat, Nov 1, 2008 at 2:19 PM, Tomas Fulopp <tomi at vacilando.org> wrote:
> The on-going debate of pros and cons of issue/post/patch voting or
> subscription is largely hypothetical: neither camp has strong proofs they
> are right. (It is further clouded by the other part of the patch delay
> problem, which is lack of superbly experienced Drupal coders who actually
> are able to understand and intelligently review the more complicated
> patches.)
> But remember the other reason to install at least subscription to individual
> issues: we would get rid of all the "+1" and "subscribing" little posts that
> plague many threads and make them hardly readable.
> If then we had a way of selecting posts with patches sorted by number of
> subscribers, we'd be able to see what patches are most sorely needed to be
> reviewed and committed. Linking that to the d.o. menu would help a lot, too.
> In 6 months we can evaluate whether or not such issue subscription sorting
> helped the whole patch stalling situation. I believe it will, but even if it
> won't, it will be extremely useful.
>
>
>
>
> On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube at yahoo.com> wrote:
>>
>> voting will not solve the problem , popularity factor is already one of
>> causes of problem. The problem stems from lack of fair way of defining how
>> critical a given issue is. Right now everything to do with D7 currently gets
>> most attention, leaving the bugs in production releases with lack of
>> attention from the community.
>>
>> There should be a queue based on a factor which defines fairness something
>> like this ,
>>  Secuity > known bug/patch > issue
>>  core > module
>>  Current Stable version ( 6) > last stable version (5) > development
>> version (7)
>>
>> Of course there is also a need for some kind of accountability as why a
>> patch for a bug in production version has not been committed for x.y.z time
>> period. But we can ignore that ...being an open source project ;) .
>> Currently new release is favored over resolving bugs in current release.
>>
>
>



-- 
Ashraf Amayreh
http://aamayreh.org