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

Quintus | Mon, 27 Jul 2015 09:31:26 UTC

Chris Jacobsen <…9@y…> writes:

> 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.

This is basically what my former, unpublished document was outlining. It
laid down basically everything related to the project, but it was about
six pages long. I was under the impression that so much formality is
more hindering to the project rather than benefiting it. Thus, I
extracted the part that was most important in my mind (voting rules),
and concluded that the rest might be doable just by talking and
developing an informal consent.

I still think so. We’re not the size of the Debian project with their
comitees, project secretary, a complicated algorithm for computing a
vote result, General Resolutions, and what not. I just want to take the
heat out of the most controversial area, and leave the rest open to a
set of not even a dozen rational human beings :-). If TSC unexpectedly
grows to a giant community and development team, we can still evaluate
the need for more extensive formal guidelines. Until then, we can
probably resolve any issue on a case-by-case base by some postings on
this ML or in IRC, except as said for the voting permissions, which are
pretty guaranteed to cause problems if not well defined.


> 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 equal."  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.

Yes, that was it was intended to say. Simple example: We vote on a set
of story documents and decide document 2 is to be used. Three years
later we want to add a new campaign to the game with a new story. Shall
the vote still bind us? I think no, which is why I added this “given all
circumstances equal” clause.

I realise it is a bit vague, but I wasn’t able to come up with a more
clear statement, which might indeed be useful. Do you have something in
mind that would fit the purpose better?

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

Okay, maybe we need to add this then indeed. How about inserting another
paragraph after §1 like this:

        -------------------------------------------------------
                       §2 Acquisition of membership

The team decides by vote whether any person should be granted team
membership by adding him to the GitHub organisation. Before this vote
can be called for, the person in question has to either

  1. have five commits included into the main development branch of the
     game, or
  2. have been nominated by an existing team member.

The vote requires that two thirds of the existing team members vote in
favour of adding the new person to the team.

In case of Nr. 1 above, as an exception to §4(1) [= current §3(1)] the
person with this amount of commits included is also allowed to place the
vote request on the project lead.
        -------------------------------------------------------

The following §§ will then just get a higher number. Alternatively, we
move this towards the end of the document, next to the current §18. That
would have the benefit that all votings demanded by the document itself
are grouped at one place, which may systematically be nicer. Might also
be useful as the exception in the third paragraph above would then not
point to a § that actually comes later.

The document should be well-structued in any case, so it is more easy to
read and to comprehend.

> We should seek out feedbackfrom other team members before defining
> this rule, however.   We should probably define this inthe document,
> too.

So it gets long and longer... :-). Still I see the need. I made a
suggestion on the acquisition, so I think you can now make a suggestion
for removal drawing from the points we have already mentioned (like
inactivity for one year or so).

> I don't think we're going toget much feedback
> from the team on this or the other questions over the mailing list,

Remember that this ML is mirrored to the forum. Everybody can particpate
from there just fine.

Valete,
Quintus

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

GnuPG key: F1D8799FBCC8BC4F