Grant Goodyear <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 13 Mar 2007 19:25:23 -0500:
> Robin H. Johnson wrote: [Tue Mar 13 2007, 06:05:10PM CDT] >> On Tue, Mar 13, 2007 at 04:09:53PM -0500, Grant Goodyear wrote: >> > * Can we find a better name than "the Proctors", please? >> >> Suggestions welcome. We were stuck for other suitable names, and it was >> my own suggestion for proctors, based on the dictionary definition: "an >> official charged with various duties, esp. with the maintenance of good >> order." [1] > > Ubuntu uses "Community Council". I suggested "Community Relations". [I'm replying here as this subthread most directly addresses the concerns I too have, but I'll reference other threadlets as well.] "Procter" seems the precise dictionary definition of what I believe we are after, but if people aren't familiar with it, as seems to be the case... Someone suggested "Communication's Supervisor", which should be simple enough but might be confused with parts of infra. What about "Gentoo Communications Representative" (tho that sounds like userrel/devrel)? Or, getting the authority in there, "Gentoo Council Communications Envoy"? >> > * I highly recommend reading http://www.ubuntu.com/community/conduct >> > and our new doc side-by-side. The former provides strong, positive >> The Ubuntu guidelines are well-mirrored in the existing etiquette >> policy: >> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml? part=3&chap=2 > > One may argue with the content of either the old etiquette guide or the > Ubuntu Code of Conduct, but I suspect that most would agree that the > Ubuntu Code of Conduct is both more encouraging and better written. I > think it's also much more encouraging and better written than is the > proposed doc, as well. I agree. Regardless of the content and tone, which can be argued, the Ubuntu CoC has things in a clear and logical order, making clear the goal before describing the behavior, then describing behavior that matches that goal, then describing certain behavior that does /not/ match the goal and is therefore discouraged. Finally, the authority and who is responsible for enforcing the policy is noted. One other point. It's quite clear throughout the Ubuntu doc who is being referred to. One of the big problems with the proposed Gentoo document IMO is that in its current form it uses the term "we" far too often, often even in the first sentence of a section, without noting who "we" is except at the top in broad terms (Gentoo). Only the corporate whole "Gentoo" does not fit the usage of "we" in some instances all that well -- a more natural fit would be the enforcers (whatever they may be called) or perhaps the Council, and thus Gentoo thru it. >> However the existing policy has not worked. Reasons and theories behind >> why are rife within Gentoo. > > You're arguing that a much more punitive doc is required because the > previous doc has been ineffective? That's a reasonable argument, but I > don't think I agree. The previous doc had no "moral weight", so to > speak, because it was imposed on devs without any real discussion, and > that's made it hard to enforce. I'd argue here a position I haven't yet seen... exactly. IMO, there are/ were two problems with the current /developer/ etiquette policy. First, it was both in the developer manual and by wording targeted specifically at developers. Non-developer participants in the various communications channels likely will not have seen it, and where it was, it /was/ a bit easy to "forget" about, even for developers that /had/ seen it. It wasn't as if it were channel communication policy, posted or linked prominently at the entry or in each location, so it was easy to "forget" (aka "ignore", if it were deliberate, but let's just assume it's not for now). If it's more visible to everyone, and is generally accepted as applying to all, perhaps it'll be easier to "remember". In line with that observation, a suggestion -- /only/ a suggestion, as I'm sure some won't like it, but I think it needs considered, anyway. Many web forums and IRC channels have a "sticky" guide or at minimum, a link to the rules, visible whenever one enters. That's not so easy on mailing lists or newsgroups. However, newsgroups at least have an accepted solution: a FAQ posted periodically (say biweekly or monthly). Many mailing lists have a subscription/unsubscribe/help reminder sent out periodically, so the idea isn't entirely foreign there either, altho posting of a (behavior) FAQ is a bit less common. I think we seriously need to consider it. We could in fact combine it with a periodic unsubscribe help mailing (which might eliminate a few of the occasional mixed up unsubscribe postings to the list, as well), since Gentoo controls its own mailing lists. Second and I think more important, given it has been developers and former devs that have been the major problem, it wasn't the lack of teeth of the former /document/ that was the problem, but rather, a lack of means or will to enforce it, directly and in a timely manner as applied to the communications channels (this mailing list in particular, in this case). Largely by deliberate design, the devrel discipline process is bureaucratic in nature and requires time, both to ideally enable a cooling off and avoid further dealing with the issue in the first place, and to ensure full due process. While the degree of that can be argued, I think most here will agree that to /some/ degree it's a /good/ thing -- after all, we /are/ talking about possible termination of a dev, when it comes to devrel. I believe the problem was that the by design slow process of dev discipline simply is not suited to resolution of the fast developing issues on the mailing lists (and the same may apply to other channels as well). Yet we (Gentoo) were trying to make it work, and we are where we are as a result. Thus, I don't believe a draconian document is called for. It's not the content at fault, but the location and the enforcement "impedance mismatch". Correct those, and the problem will be /much/ easier to correct as well. >> > [I agree] that a few days isn't really enough time for an adequate >> > discussion. For this sort of policy to be effective, devs need to >> > agree with it. The Council can still make temporary rules on >> > Thursday while allowing the rest of the process to occur more >> > leisurely. >> As the council[, we are] saying that the buck stops here, because >> right now, Gentoo is being seriously damaged as a distribution. > > I simply > think you folks are rushing things more than is really necessary. Take a > look at yesterday's threads started by Mr. Long. He was stirring up > trouble, and he was not terribly successful because, after a bit of > latency, people refused to play along. That's a positive change that I > suspect occurred at least in part _because_ the Council is leading here. > I think the Council is already making a difference, and that there's > time to come up with something beautiful instead of just functional. I don't think it's the council yet. I think it's still the "shell shock" speaking. Nobody who went thru that wants to see anything like it again, certainly not now, so everyone's being especially cautious on the one hand, and on the other, like many air passengers today, we simply aren't going to play along any longer with potential hijackings, and they no longer tend to work. I think the council's worry is two-fold. First, Gentoo must be seen to have taken some action to stem the damage, or we'll lose even more credibility (and likely attract more trolls out for some fun... unfortunately). Second, that post event watchfulness may not last forever, and the council wants something in place before it's gone. Those are both very reasonable, but I too agree with you and others, the current draft just doesn't cut it as a long term document and if we try and force it to, we're likely to be dealing with some other crisis as a result some time down the road. What I think may be the best that can be done under the circumstances is to adopt this document (as can be best modified in the next xx hours) as a say 40-day policy, auto-sunset, thus guaranteeing we aren't stuck with it beyond that term. That then gives us the rest of the month to hash out a better document, hopefully to be adopted at the next regular council meeting, and a few days further to implement it in an orderly fashion before the temp policy expires. If the permanent policy isn't ready by that time, the council can then extend the temp policy another 30 days, and there should be little reason found to extend it yet again, as the permanent policy should have been hashed out by that point, or / possibly/ after a bit of time, they/we might see a different, better approach, and not need either a further extension of the temp policy or implementation of a direct replacement. >> > * Having a group of folks separate from devrel who would be doing >> > similar things to what devrel does (when devrel isn't involved in >> > recruiting) somehow seems a bit silly. I'd much rather we just >> > broaden that part of Developer Relations to Community Relations. >> I'd to quote from Christel's mail here: "2. The Proctors is not a new >> name for Devrel. They would fall under Devrel territory, but as a newly >> formed group under the leadership and supervision of the Council. A >> decision as to numbers and electing proctors has not yet been reached >> -- we are working out these details as we speak. > > *Grin* I actually did read Christel's e-mail. I disagree with that > part. If my argument above is assumed to be correct, then it should be obvious that devrel in its current form isn't right for the task. First, it's /dev/rel, and we are talking a communication channels policy applying to all users, including but not limited to devs. Second, there's the timing thing. Now, it might be possible to give them the power to act in appropriately short time here, while continuing the full due process procedure for questions of dev discipline (as opposed to comm channel discipline), but there's no reason it /has/ to be them, given the timing difference. Additionally, we /are/ talking a policy applying to users as well, and I believe the idea of a wider community representation is sound in that regard. By the same token, I honestly can't say whether devs will find it acceptable for a group with a significant non-dev component to be doing the devrel task, so it's really two widely different tasks, and I think it works best as two different groups. By the same token, however, I don't see a problem if most or all of devrel end up as proctors. However, I believe the groups should be independent, and likely, that "comrep" should be accountable directly to the council. >> (My suggestion here is to select a group of people from a wide variety >> of backgrounds within Gentoo, taking care to avoid 'old boys clubs' and >> cliques)" >> >> Simply renaming devrel to commrel and handing them the task won't solve >> anything - there will still be complaints that devrel is being unfair >> (and is indeed why your Ombuds position exists). As the council, we >> will require of the Proctors that they are impartial and fair. > > Here's my problem with it: essentially what you're arguing for the > proctors to be is the same as what devrel should be (at least for the > part of devrel that is supposed to be looking after community > standards). To me it's two different groups, two different tasks. The one deals with developer relations, in the worst case leading to developer termination. That /should/ be a task that takes a bit of time, with additional due process protections built-in. The other deals with community communications channels, in the worst case leading to permanent termination of voice in one or more of those channels. While that has a direct significance for the dev's ability to properly do his work as a dev, user implications are much more muted. Additionally, I see a STRONG benefit in the ability of the "comrep" group to order a 3-day or 1 week cooling off period WITHOUT it directly interfering with devrel status. In fact, one could claim that part of the paralysis in the current situation had to do with the fact that getting devrel involved was a BIG step, something folks often hesitated to do until too late. If the two processes were independent of each other, a short term cooling off period of a few days would be MUCH more likely to be imposed if arguably necessary but not debateably borderline, as it wouldn't be such a drastic step in all those OTHER ways. As such, weaker consequences earlier are likely to be imposed, hopefully avoiding the necessity of even /debating/ stronger consequences later, as /well/ as applying the brakes before anything like the debacle we recently witnessed happens again. >> > * Ubuntu requires that their devs sign a copy of their code of >> > conduct. >> How do we enforce this on users (both those that were never developers >> as well as those that were ex-developers) fairly then? I see equal >> enforcement as a benefit here. > > One might argue that devs should be held to a slightly higher standard > than the users. My understanding is that w/ Ubuntu the devs sign the > code because they are the standard bearers of the distribution. Their > views are going to hold more weight in the community because of that > ubuntu.org e-mail address, and by signing the code they provide a good > example for the users. The users are expected to play by the same > rules, but of course they don't have to sign anything; it's implicit by > signing up on a mailing list (or forum, or whatever). > > *Shrug* I don't really have a strong opinion about this last item. I'm > just trying to offer things to think about. I agree, same rules, enforceable on all, but having devs sign (plus putting a question or two on the quiz dealing with such things, not because anyone will answer wrong, but because it'll bring the awareness up) increases their awareness of it in approximate degree to which their visibility as Gentoo representatives is increased. The question then may come up, what happens if someone can't or doesn't wish to sign for some reason? My opinion? Again, it's an awareness thing. By indicating they can't sign it, they've indicated that they are aware of it, and if the policy is that as a dev they will be held to it regardless of whether they signed or not, with their devship ultimately hanging in the balance if they disregard it, well, they then know that whether they choose to sign or not. It's a signature of awareness, not of agreement, and choosing not to sign indicates the same thing. The policy gets applied the same whether they sign or not. Still, as the others, no strong opinion here, just opinion. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
