In reference to the published document, I had noticed its emphasis on democratic procedures.  Thus,
in order to be a document for a "pure democracy", there should be a formal procedure to elect
new project leads, assistant project leads, or other positions that we create.  Note that I am
*not* calling for anyone to be removed from their formal positions.  I'm just saying it's something good
to have in writing and is something that is related to voting execution.  It also allows the team
to reorganize more quickly if something happens to the project lead or the assistant project lead.

The document says, "It is a binding decision that determines how to proceed in the given topic and
prevents any further vote on the topic given all circumstances equal."

I assume all circumstances being equal means the conditions that led to the vote have not changed and
that a new vote could be held if conditions do again change.

The posted document otherwise looks very good (and detailed), except for the prior question on how to add
new team members to the github organization.

> I’m mostly okay with this, but I’d like to have a vote either way. We
don’t want to encourage people to break up their contributions so that
each letter gets a separate commit just to have them cross the magic
threshold that makes them a team member with voting rights

This makes sense.  More or less commits should be based on what helps people develop and/or
benefits the git history, not attempts at voting power.

> We could place the hurdle rather low. One TSC-related post (i.e. not an
offtopic “here’s my cat video”) could suffice.

This probably makes sense, since we don't want people on the team to feel like they are under
pressure to get X number of commits or Y number of postings in per year.  People should
make contributions because they feel involved and want to help.  We should seek out feedback
from other team members before defining this rule, however.  We should probably define this in
the document, too.

You have brought up valid points on giby's membership, and I understand your concern about
not setting a standard by which we become flooded with members.  I don't think we're going to
get much feedback from the team on this or the other questions over the mailing list, though.
Anyways, if we have at least given fair discussion to this before the next team meeting, that
was my minimal objective.

If the bar to entry it way too low, the content contributors could feel outvoted by people who
are not content-contributors.  If the bar of entry is too high, people who are the most faithful
beta testers or who do work such as system administration could become angry about having
no voice and leave.  Hopefully careful discussions and voting on team members will make the
right decisions.

> Can we postpone the question of
whom to add/remove to/from the organisation until we have all agreed on
the rest of the voting rules document then?

I said more than I meant to before, so follow whatever procedure would have normally have been
followed had I not asked so many questions about this.

Before removing people at some point in the future we could consider sending them an email asking if they intend
to stay involved or not and let them respond.  It's a possible option, though we'd probably still have
to have a formal rule in the long term.  We should also let them know their contributions were valued
and that we hope they find time to contribute again at some point in the future if they have time.


On Thursday, July 23, 2015 1:06 PM, Quintus <> wrote:

Okay, if I see this correctly, then everyone is fine with voting rights
being tied to the GitHub organisation. Can we postpone the question of
whom to add/remove to/from the organisation until we have all agreed on
the rest of the voting rules document then?

Up until now no concerns other than the discussed one about the GitHub
organisation membership have been raised. I’d like to see more people
taking part in this discussion, though, as the voting rules are
something pretty fundamental for our continued development of the TSC
project. I appreciate it if everyone likes my draft, but now is the time
to properly discuss its fundamental outlines. Later changes will require
a 2/3 majority among the team members, so if you don’t make your
suggestions now, it’ll be difficult to get them in later.

Once no further changes are suggested, I want ideally all people in the
team to indicate that they’re fine with the document. The more agreement
is there, the better the foundation is.




GnuPG key: F1D8799FBCC8BC4F