[drupal-devel] more core comitters

[Bèr Kessels]

Hello,

Can we now close this thread? 

Without becoming too political or theoretical: rogramming for an OSS system is 
not a democratic process. Essential it is more anarchistic: bugs are fixed 
ad-hoc. Code that is written is more valuable than the most brilliant idea 
that exists as idea only. 

So: whatever solutions are brought forward: voting systems, ratings, 
role-based value systems:Only in those places issues where work is done, and 
where attention of others is focussed, actual changes will take place. 

Rating, ranking voting cannot be coded in programs or systems. It just 
happens. Patches are committed whenever they are ready to. not just because 
the system tells it has a lot of points.

Indeed, the mantra, above all, is more hands. All we can do, is make sure the 
work that these hands do does not get lost. For, IMO that was the main 
problem: a lot of good patches were waiting, but became somehow crufty. I am 
confident, though that the current renewed patch queue will bring some 
improvement. 

I would therefore like to see this thread and discussion be put to halt, 
untill the day that the current solutions prove to be insufficient, if that 
ever happens. 


Ber

Op maandag 01 augustus 2005 16:50, schreef Jose A. Reyero:
> Dries Buytaert wrote:
> > On 30 Jul 2005, at 18:28, Dries Buytaert wrote:
> >> The patch is live on drupal.org.  What remains to be done is
> >> defining new status values.  Let's do that now.  Here are some that
> >> could be useful:
> >>
> >>   1. Needs code review
> >>   2. Needs testing
> >>   3. Needs benchmarking
> >>   4. Needs update/work
> >>   5. Needs feedback
> >
> > OK, I setup 3 new categories:
> >
> >   1. patch (code needs review)
> >   2. patch (code needs work)
> >   3. patch (ready to be committed)
> >
> > We can refine or reword these later on.  Right now, all patches
> > default to 'patch (code needs review)' so we'll want to work our way
> > to the patch queue and update the patches according to the new fields.
> >
> > Thoughts?
>
> These new options sure will be an improvement. The problem that still
> persist is the cycle of updating/reviewing/testing/approving, with some
> issues becoming long long threads to read, and also who takes the
> responsibility to update status for a patch, and whether you can trust
> that person's judgement or not.
>
> One way to address this could be approaching it as a rating system
> better than a simple 'status' field. I'm thinking of a 'moderation
> queue' like system, in which several users/reviewers could post their
> votes on a patch. Then you -or someone reviewing patches for final
> 'commit' could see it like:
>
> - 6 people are against this specific feature (list...)
> - 5 people thinks patch needs work (list: user1, user2,...)
> - 4 people thinks patch is ready to be committed (list....)
>
> Reviewers should be able too, to change their 'vote' on the patch once
> its been updated.
> Votes like 'ready to be committed' could be restricted, by role, to a
> reduced number of users. Or votes could be weighted depending on some
> 'trust level' assigned to each users.
>
> I know this 'rating system' wont be easy to implement. But once its up
> and running it coul be the killer feature for speeding up patch
> reviewing. You could also have some filter system, so only patches that
> already have a number of +1 reviews will have to catch your attention.
>
> > --
> > Dries Buytaert  ::  http://www.buytaert.net/
Regards,
 Bèr
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]