Hi,
Before I say anything else, I'd just like to say I'm sorry for all of
this. Exclusion was not my intention at all.
On Wed, Jul 8, 2015 at 8:36 AM, Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:
It would be pretty easy to write a similar, serious-sounding mail proposing
revoking commit access
if one breaks the build and doesn't fix the problem in, let's say, 3 hours.
What would be the point
of such policy though? I mean, aside from trying to reduce number of
contributors to 0. Do we
really want to say now that each decision one makes must be discussed with
the other members of the
project otherwise if there are objections someone would propose revoking
some of your powers? Sure,
there are things that need at least ack from the others, but the line is not
always clear and we
can't punish people for minor mistakes even, especially if they did it in
good faith. If we tried
to discuss everything first it would take ages to do anything.
I agree that in this particular case there shouldn't be any doubts that any
action should be
discussed beforehand and I definitely don't agree with making #haiku only
for registered users. So
what? The change like this can be always reverted and waddlesplash,
hopefully, will be more careful
next time. No need for any "disciplinary committee" or spanish inquisition
(well, I certainly
didn't expect such reaction). One may even argue that proposals such as this
are more harmful to
the community than temporary restrictions in access to the IRC channel.
The difference is, on one side there is commit access/project membership
(currently these are indisociable in Haiku), which grants you the right to do
anything you want with the code, without necessarily having to discuss things
first. We did already ban someone from the project (only one time, as far as
I know). This was a difficult decision and somewhat harmful for the project
(it's hard to know what would have happened had we made a different decision).
On the other side, there are a set of "administrative" positions, like being
an op on the IRC channel, system administration of our servers, etc. For
these, we can only have a restricted number of people taking care of them,
because otherwise (with all developers trying to help) it would be a mess.
However, this does not (and should not) grant them any "superpowers" on the
project: people occupying these positions are supposed to only execute
decisions made by the Haiku project. Unless, as I already mentionned, there
is an emergency (people really crossing the line on the IRC channel can get
banned temporarily, a crashed server putting our services offline should be
fixed as fast as possible, etc).
A similar incident in the git server side would be one of the admins deciding
to add or remove commit access for other people without asking this list
first. What would you think about that?
There are two consequences to this:
1) It is not acceptable to use this position as a way to bypass the decision
process,
2) Removing access after an incident is not a sanction (it does not exclude
people from the project, and only removes from them the burden of doing these
annoying management tasks).
Since these rules are still unwritten, we can assume ignorance (I think it
was, in this case), and decide to only do a warning (I think the existence of
this thread is a good warning). And we should invest some time in writing
down the rules to avoid such mistakes in the future.
