Re: [tsc-devel] RFC: Voting rules draft
Quintus |
Sun, 02 Aug 2015 19:19:44 UTC
Chris Jacobsen <…9@y…> writes:
> We might consider eventually having multiple documents that aren't too
> large if we need this level of detail in rules, but you have a good
> point that for now we probably don't want to over legalize our team.
For now I think this approach is feasable. Once we have accumulated five
or more documents we ought to restructure them in one again, though,
otherwise it gets messy.
But as said, currently I think the one about the voting procedure is
enough.
>> 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?
>
> I just wanted to double check. Whether something can be revoted could become a matter
> of disagreement down the line, though I guess we can always use informal consensus or just
> vote again if warranted.
Okay. We will look at how this clause will act in practise, and if
required, we can still propose changes to it later.
Regarding your suggestion:
> There are 3 ways by which a person can be removed from the core team:
> 1. The person can request removal formally
> 2. If the person does not show any activity for a year, they will be removed. The minimal
> activity required is one forum/tracker post (advancing TSC
> discussions) or commit in source control per year.
Ok.
> When two weeks are remaining before a person reaches the one year mark
> for inactivity, an administrator will send an email to the inactive
> person asking about their involvement.
Can we change “administrator” to “project lead”? Not that I want to be
of importance, but the term “administrator” is used nowhere else in the
document, and the administrative tasks in the project are usually duty
of the project lead. The document also says that if the project lead is
unavailable the assistant lead takes over, so I don’t think we’re going
to fall into a gap then. Having the entire document using the same terms
will prevent confusion on its contents.
> If they do not make
> a posting or commit, or if they do not respond, they will be removed from the team.
> 3. The team reserves the right to remove any person at any time, for any reason, through a vote. This
> requires a two thirds majority, and the candidate for removal is not allowed to cast a vote. The team
> is expected to try to follow fair criteria for such removals and consider changing the rules if repeated
> removals occur.
>
>
> Upon removal a person will be removed from the github organization. They can be readded at any time by
> meeting the criteria for a regular team addition.
Ok.
> I think the term will stick out and that people may get worried about
> it. I don't think most people will question our usage of the term
> democratic, but if it is a concern it would be better to use no
> -ocracy term at all than something that might stir controversy later.
> I do appreciate Luiji's attention to detail on this, though.
I’ll try to come up with something without *ocracies then in the
preamble.
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F