[haiku-development] Re: [proposal] removing waddlesplash from #haiku IRC channel operators
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 08 Jul 2015 12:36:58 +0000
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.
--
Adrien.
Other related posts:
