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 electnew 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 goodto have in writing and is
something that is related to voting execution. It also allows the teamto 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 andprevents any further vote on the topic given all circumstances
I assume all circumstances being equal means the conditions that led to the vote have not
changed andthat 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 addnew 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/orbenefits the git history, not attempts at voting power.
We could place the hurdle rather low. One TSC-related post (i.e. not
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 underpressure to get X number of commits or Y number of postings in per year. People
shouldmake contributions because they feel involved and want to help. We should seek out
feedbackfrom other team members before defining this rule, however. We should probably
define this inthe document, too.
You have brought up valid points on giby's membership, and I understand your concern
aboutnot setting a standard by which we become flooded with members. I don't think
we're going toget 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, thatwas my minimal objective.
If the bar to entry it way too low, the content contributors could feel outvoted by people
whoare not content-contributors. If the bar of entry is too high, people who are the most
faithfulbeta testers or who do work such as system administration could become angry about
havingno voice and leave. Hopefully careful discussions and voting on team members will
make theright 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
beenfollowed 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 intendto stay involved or not and let them respond. It's a possible
option, though we'd probably still haveto have a formal rule in the long term. We
should also let them know their contributions were valuedand 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 <quintus(a)quintilianus.eu> 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