On Fri, 2019-01-04 at 23:56 -0500, Scott Kitterman wrote: > No. That's not how Debian works. This is a volunteer effort, not a > bureaucracy. Delegates are delegated certain authorities and it's up > to them to decide how to exercise them. If the larger DD community > sufficiently disagrees, they can raise a GR on the matter (but please > wait until we hear from them as a team and only if you are really, > really certain - overriding a DPL delegate is a major thing). I was waiting for someone to say "but ... Debian's different". No, it's not. For a start I am genuinely puzzled by you saying Debian doesn't have a bureaucracy. To me it seems Debian has a much larger bureaucracy than most 1000 people organisations I've deal with. We have lots of cogs like the DAM grinding away in the background (so many in fact I'm sure I don't know them all), court like entities like the TC, more written rules than I've seen in most large organisations. That aside, "That's not how Debian works" sounds like the height of hubris to me. Getting groups of unfamiliar people with different backgrounds and values together to work towards a common interest is something we have been working for centuries. In fact finding better ways to do that is probably what has propelled Western society to its current pre-eminent position - governments, democracies, corporations, trusts, charities, churches, the number of ways we do it is mind boggling. Underneath all of them lies some common elements, which you can pick up for free where I live from most government offices by asking for "model rules" or "model constitution". I gather Debian did not do that, because if they did they would have got their first expulsion process and we would all know what it is. Yet here you come along claiming Debian has found a better way, which apparently is appoint people while providing no written guidance on what they are expected to do, but we fix that having a GR if they displease us. No, just no, it is not a better way. Besides your wrong. In most things Debian does we have do have policies, reams of them in fact. Policies saying how people join, how they retire, how they resolve technical differences. This expulsion thing is not the norm - it's an aberration. Most GR's are about changing our policies as we learn, not telling teams they have done something bad. > I think you don't have much experience with these kinds of things if > you believe that. I don't know what "things" you are referring to, but if it is working in large community groups like "Debian" you are again wrong. > On the FTP Team (of which I'm a non-delegated Assistant) it can take > weeks to get agreement on text to send out on an issue. The email I > sent relatively recently to d-d-a regarding the team's view on > listing individual copyright holders in debian/copyright was > literally months in the making. You are comparing the workload of the FTP team which has to deal with many issues a year to workload of imposed by an expulsion process when has been used only a few times in Debian's history. I trust you see the obvious problem. Obvious problem aside, we apparently think it is necessary to insist the Technical Committee provide similar a justification on the cases they decide upon each year, yet you are apparently are think asking the people who expel members to do the same thing is imposing an unreasonable workload. Is how we deal with each other so unimportant? It probably isn't, because that effort you say is so unreasonable - the the DAM actually do it. Did see read the their private email to the person concerned - that would be it. This thing you are focusing on, the written justification wasn't the change I was asking for as they mostly do it now. I was asking for something entirely different - transparency. > Taking care to make sure an email speaks for the team as a whole and > is correct is hard and takes time. Indeed, damned hard. Can you imagine then how hard it must be for the DAM to speak and act for the whole project? Yet we ask three people to do just that. They had not formal training for it (unless they come from a HR background - I don't know), we give them little guidance, almost no feedback until incidents like this occur because you can't provide feedback without a little transparency, and then you pop up and say don't worry - we don't have clear standards we expect you to uphold - Debian doesn't work like that. We will just GR you if you get it wrong.
Attachment:
signature.asc
Description: This is a digitally signed message part