Re: infrastructure team rules (second edit)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 23-10-2007 06:01, Marc 'HE' Brockschmidt wrote:
> Clint Adams <schizo@debian.org> writes:
>> On Fri, Oct 19, 2007 at 04:43:09PM +0200, Josip Rodin wrote:
>>> If the team is functional, why would we even consider someone/something else
>>> deciding it? Revoking the teams' right to decide their own membership would
>>> go against all recorded history (AFAIR), so one could question whether that
>>> kind of a change is done in good faith.
>> I was under the impression that recorded history proves that this does
>> not work and is prone to all kinds of abuse.
>
> Actually, it's the way the release team has been working for some time
> now. I have the impression that the RM team works just fine and doesn't
> have the problems that are to be solved by these rules. It may be argued
> that the release team is not an "infrastructure team", but the concept
> is the same.
Ok, so if one team can work well without the rules,
shouldn't we ask ourselves where is the real problem? I tend
to be more practical in most situations, and if there are
teams working really great, I can't believe that we can't
find out what's is the real problem and work on that.
If, for instance, we need to change people and we
are creating the rules just to allow us to remove them or
to interfere and ask for the change, then I think we need
a better approach.
I like the idea of having better team rules but I also
think that if we have a very good example of a working team,
I tend to believe that teams with functional problems should
be probed to work on that.
The problem seems more to be the identification of
what is disrupting the team, and if it is some what related
to the fact that people like to do the work they do on that
team but they can't tolerate another existing team member
or they can't stand for some decision, IMHO we should try
to aim to work on solve the situation, because I keep asking
myself if the rules might have a negative effect on healthy
teams?
I really can't imagine the best approach to work on
such cases, things like "replace the entire team" or "remove
half of the team" (or anything with remove/replace somebody)
doesn't seem to work, specially if we didn't work on the
reason that made the disruption, then we will be working on
replacing people and try to fix teams from time to time,
because the real cause is still there. If frustration for
some reason with another team or some part of the project is
one of the factors, shouldn't we also work on that?
Unfortunately, we need people to *talk* to understand
what happened, I can understand that some people would not
want to speak about something or would imagine that outsiders
wouldn't understand what happened at a given time, and by
looking under that perspective, we add a communication problem
to the equation.
I would like to hear more from people that are involved
in teams considered problematic to try to understand, specially
to see if they have an idea of how it could be solved, asking
shouldn't hurt. Otherwise, vote on this can become even harder.
I had the impression that Sam (DPL) worked a lot in this matter,
perhaps he has some ideas/impressions/conclusions to share.
I had the impression that the third edit tries to write
down good practices and common understanding of how it should
work, it is really a nice work, my e-mail is not against it,
I'm just trying to share some concerns about how we could work
(help/improve/help to improve) some areas. :-)
Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHHexjCjAO0JDlykYRAkLpAKCvFwDx0EXpTb8QBYXPmn2OGfNIfwCgjnK5
v6L8ncn5CGZvH+cC/fZle6g=
=M5yf
-----END PGP SIGNATURE-----
Reply to: