Re: [tsc-devel] RFC: Voting rules draft

Quintus | Sun, 19 Jul 2015 17:42:02 UTC

Chris Jacobsen <…9@y…> writes:

> We also could account for things such as activity on the
> forums/tracker, engagement in IRC, and help with beta testing. This
> would allowpeople who provide repeated feedback or help with things
> other than content production to have a real voice.

Yes, but it is too vague. It must be avoided that there is any dispute
about whether someone is allowed to vote or not; the issue that is voted
upon is controverse enough, further complicating it by having an
argument about whether someone has done enough for TSC to be able to
vote seems not very good to me. At vote time, I want a criterion that
can quickly be determined without dispute.

> Having people who are in the organization be the ones who vote is the
> easiest as you said. Thus the easiest solution would be to addpeople
> who have made non-content-based contributions to the organization in
> order to formalize their voting power.

I am fine with this. While no votes are being run, the team can decide
at any time to add somebody new to the GitHub organisation, preferably
with consent. I was earlier working on a more comprehensive document
that included rules about adding people to the team, removing them,
project leadership, and other issues, but I came to the conclusion that
it would be too large for our small team. Too much formality hinders the
development process, but I do think that the controversial area of
voting needs definite rules everybody can refer to.

That document included a paragraph that said that everybody who had at
least one commit accepted into the “devel” branch was eligable to be
added to the GitHub organisation. The actual addition however was to be
determined by consent or, if impossible, by a vote that required a 2/3
majority in favour of the addition.

As for removal, it said that after somebody did not interact with the
project for one year, he should be removed automatically from the
organisation. That only as a side note for completion.

> In giby's case, besides working on the French translation, he has also
> been active in IRC, led the recommendation to use Transifex (notused
> but spurred discussion), has been active occasionally on other tracker
> tickets, and had offered to help with the Mac port if possible.

I don’t think I’ve seen him taking part in IRC discussions much. He did
contribute the French translation, yes, but I am unsure if I’d have that
suffice for team membership. To be fair, I’d say the same about danfun
for example. Once somebody is in, removing him again is much more of a
controversial issue, which is why I’d rather keep the team
small. Another thing I’d like to avoid is that we have 50 team members,
of which then only 5 participate in votings and 25 disappear after half
a year completely; that’d be fairly absurd. In short, if I grant someone
team membership, I expect him to care enough about the project to
actually follow the development, make contributions or participate in
discussions more or less regularyly, and make use of the vote right he
has. People who are at the edge of vanishing shouldn’t be included into
the team.

People who do not follow TSC development continuously, but only
sporadically, are still welcome to make PRs or participate in
discussions of course. Their input and contributions will gladly be
accepted. However, I have trouble making anybody who only appeared two
or three times, with a lot of time in-between, directly a team
member. To explain graphically, I imagine the people interested in TSC
as a pyramid (ASCII art follows; use a monospace font!):


                           /\
                          /  \
                         /    \
                        / Core \
                       /  Team  \
                      /----------\
                     /  Contri-   \
                    /   butors     \
                   /----------------\
                  /       Power      \
                 /        Users       \
                /----------------------\
               /       Occasional       \
              /          Users           \
             /----------------------------\
            /           Anybody            \
           /             Else               \
          +==================================+


From this pyramid, I’d give only the “Core Team” people voting
rights. People who occasionally help the core team I qualify as
“Contributors”, and while their help is greatly appreciated, I don’t
think they should be allowed to steer the project direction by
voting. Maybe we can give them other advantages depending on how
recently they contribute while they’re under the threshold for
qualifying as a core team member, but giving them the right to vote
leads too far in my opinion. If they want to get a handle on the project
steering, they should proof their interest by making enough
contributions to jump over the gap and become a core team member, which
anybody should have the ability to.

Please don’t read this as an offender; I’m only outlining the views I
have on the topic and don’t want to attack anybody personally. I want to
find objective criteria that allow a good judgement of the right to vote
and team membership, that’s all.

Valete,
Quintus

-- 
#!/sbin/quintus
Blog: http://www.guelkerdev.de

GnuPG key: F1D8799FBCC8BC4F