Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano <gitster@pobox.com>]

Phillip Wood <phillip.wood123@gmail.com> writes:

> I agree we want to include those who contribute more widely, but I think 
> restricting the criteria to contributions on the mailing list where the 
> development of git takes place and the impact of any decision will be 
> felt the most is a reasonable place to draw the line. I'm not sure how 
> easy it is going to be to count reviews - does posting "LGTM" count or 
> do we want a more substantial contribution? Should verified bug reports 
> count? - that's also a useful contribution to the project.

We have patches focusing on documentation as well.  I do not think
commit count necessarily gives undue advantage to code contributors.

> I also think it would be sensible to restrict eligibility to the current 
> set of active contributors, who will have to live with the consequences 
> of the decision, by requiring eligible contributions to have been made 
> in the previous two years. I have historic contributions in a couple of 
> projects that I'm not active in anymore and I would not expect to be 
> able to influence an decisions those projects make now.

But do you care about these past projects enough to (1) notice that
they are having a policy discussion, (2) bother visiting them again
to learn their current voting procedures, and (3) actually cast a
vote to help improve them?  You may not have been active recently,
but if you care enough, and if your past knowledge of how the
project works still applies, wouldn't the project participants
appreciate your input?

I would recommend reducing the number and complexity of conditions.
Immediately after you say "last two years", I can hear someone else
arguing "too short -- why not three?" or "too long -- why not one?".
I previously mentioned "topic count", but commits are far easier to
count.  So instead of requiring two topics in released versions,
perhaps requiring five commits would be easier to implement and
explain.