[logback-dev] Running the logback project as a commitocracy
ceki at qos.ch
Fri Feb 18 23:08:52 CET 2011
On 15/02/2011 1:45 AM, Joern Huxhorn wrote:
>> 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.
More information about the logback-dev