[logback-dev] Running the logback project as a commitocracy

[Ceki Gülcü]

On 15/02/2011 1:45 AM, Joern Huxhorn wrote:
[snip]
>
>> For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice.
>>
>> git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l
>>
>> At present time, the commit-points for the logback project:
>>
>> Ceki Gulcu 486 commit-points
>> Sebastien Pennec  164 commit-points
>> Tomasz Nurkiewicz 10 commit-points
>>

 > The main problem with this heuristic is that even if I did a complete
 > rewrite of the whole Logback project over a timeframe of two years and
 > you'd just love it and decided to take all of my changes you'd still
 > apply (merge) my changes on a single day giving me exactly one
 > commit-point. Does not seem to be very fair to me.

What you describe would be very unfair. Fortunately, merging with git
preserves the author and date. If a merge objectively deserves N
commit points, the author of the contribution will get exxactly N
points after the merge.

 > I think this does only work for non-distibuted repositories with
 > multiple commiters but not for DVCS with a single blessed repository.

Nope, git merges conserve the original author and date.

 >> A committocracy may be less efficient than the BDFL model for
 >> decision making, and compared to the Apache-way, it grants less power
 >> to newcomers. However, a committocracy is a fair system in the sense
 >> that the same rules apply to all. Today's committer with the most
 >> committer-points can be different than that of tomorrow. Moreover,
 >> compared to the Apache-way, a committocracy drastically reduces the
 >> risk of a project going haywire after admitting a new member. As a
 >> corollary, a project can safely reduce the wait-and-see period
 >> preceding the admission of new committers. Thus, newcomers may be
 >> granted committership status immediately (after their first commit).

 > I'm not sure if I really understand you correctly...

 > Are you really suggesting to give up the blessed repository concept
 > and add just about everyone as a Collaborator (as GitHub calls them)?
 > I think the default GitHub way of working with pull-requests is a much
 > better and safer way of work.

Commits can be reverted if proven to be unsuitable after
review. Commitorctacy is designed to allow decision making in case a
given commit is not unanimously approved.

>> Your comments welcome.
>>
>
> I hope so ;)
>
> Sorry for ranting but I had to get all of this out of my system.

Sure. I understand that seeing one's contributions ignored/declined
can be frustrating. I am sorry for ignoring/declining the
contributions which deserved better.

> Cheers,
> Joern.

--
Ceki