Chris Jacobsen <cjj_009(a)yahoo.com> writes:
We might consider eventually having multiple documents that
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
> I realise it is a bit vague, but I wasn’t able to come up with a
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
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
1. The person can request removal formally
2. If the person does not show any activity for a year, they will be removed. The
activity required is one forum/tracker post (advancing TSC
discussions) or commit in source control per year.
When two weeks are remaining before a person reaches the one year
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
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.
I think the term will stick out and that people may get worried
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
GnuPG key: F1D8799FBCC8BC4F