Re: Community Team - where we want to go
> "Charles" == Charles Plessy writes: Charles> Le Wed, Nov 13, 2019 at 10:55:41PM +, Martina Ferrari a Charles> écrit : >> >> A short reply in a personal capacity.. Charles> Hi Martina and everybody, Charles> I have always found replies “in a personal capacity” or Charles> “with [the team's] hat off” very confusing; probably Charles> because I rarely see this communication style outside Charles> Debian. Especially when coming from teams that have quite Charles> some power, I think that it would be better for us to Charles> receive statements that reflect the consensus of the team, Charles> if necessary with some kind of addendum explaining the Charles> minority's point of view when the opinions of the team Charles> members are split in a way that it is hard to resolve. I think there are significant problems when you try and consolidate opinions in a consensus discussion. When we as an entire community are trying to figure things out, it's really hard to do that if some of us are speaking as individuals and some of us are speaking as groups. Put another way, consensus decision making requires that everyone involved in building the consensus be reasonably open to listening to others, considering how their comments affect the consensus, and being open about those changes as the discussion progresses. When some of the stakeholders need to go off and have an internal discussion, it means it is harder for a consensus facilitator (or anyone else) to see if concerns have been raised. It tends to create some unfortunate power imbalances. So, I at least find it useful especially in consensus forming discussions if people are willing to comment as individual members of teams.
Re: Community Team - where we want to go
Le Wed, Nov 13, 2019 at 10:55:41PM +, Martina Ferrari a écrit : > > A short reply in a personal capacity.. Hi Martina and everybody, I have always found replies “in a personal capacity” or “with [the team's] hat off” very confusing; probably because I rarely see this communication style outside Debian. Especially when coming from teams that have quite some power, I think that it would be better for us to receive statements that reflect the consensus of the team, if necessary with some kind of addendum explaining the minority's point of view when the opinions of the team members are split in a way that it is hard to resolve. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Community Team - where we want to go
Wouter, A short reply in a personal capacity.. On 08/11/2019 19:28, Wouter Verhelst wrote: > While I'm not arguing that we should take punitive action against > everyone who violates our current Code of Conduct in the "almost bad" > sense, there is a reason why it mentions "repeat offenders"; > additionally, I also think that the current phrasing of the Code of > Conduct allows administrators the necessary leeway to take the correct > course of action as necessitated by individual situations. > > If what you mean by "interpreting" is "eventually come up with a long > list of things not to do", then that would definitely be against the > spirit of the current Code of Conduct (at least as it was intended by > its primary author, i.e., me), and I would be disappointed if that were > to happen. That is definitely not what was intented, and I don't think anybody in the team ever thought of coming up with such a list! On the contrary, since the CoC is deliberately vague, you will encounter situations where people disagree on the interpretation. The idea of "interpreting" the CoC is to have a team that says "we think this situation is/is not/ a violation of the CoC", and that tries to do it in a fair manner. As you say, the CoC also gives tools to the administrators to disagree, and they still retain the last word without need for any kind of appeal process. >> Examples of things the team does *not* do >> = > [...] >> * Mediate communications or conversations between individuals; or > > I also wonder why you exclude this as a responsibility. I think that a > team which does explicitly not have the power to take any punitive > action (but at the same time is involved in a lot of situations like > that) would often (though probably not always) be in an ideal position > to mediate between members. What am I missing? The main problem with this is that we are just another group of volunteers with limited time and energy. Mediation work is not only difficult and requires specific tools and training, but it is also emotionally exhausting. I know I would not be able to do that for long before burning out completely. OTOH, this is something that does not need any kind of authority or delegation: saving for private communications, anybody in the community can step-up and try to de-escalate and help their peers, and I have seen this happening more and more since I joined Debian. I also think that is happening because we have grown as a community to the point where we are not tolerating the kind of toxic behaviour we used to tolerate 15 years ago.
Re: Community Team - where we want to go
On Mon, 11 Nov 2019, Norbert Preining wrote: > On Mon, 11 Nov 2019, Gerardo Ballabio wrote: > > That is, the team would rule on individual cases, rather than issuing > > "lists of things not to do". IMHO that pretty much would make it a > > court with the power to judge project members. And I'm not sure that > > the team not taking actual measures, but just making "recommendations" > > to other people who are empowered to take action, would make a > > difference. In fact, that would be curiously similar to how the > > Inquisition proceeded: technically they never executed anyone, they > > just sent people to the secular authority with the "recommendation" to > > burn them at the stake. > > > > And if the people empowered to take action can disagree with the > > recommendation and apply their own judgement, well, that would make > > the "ultimate authority" concept void, and I would say, would nullify > > the whole point of having the team "interpret the CoC". > > +1 -10 for introducing a comparison that has no place in Debian. We're not executing or burning people. That's the kind of comparison that contributes to the bad atmosphere and is pushing reasonable people to add more rules, so this goes towards your own goals of wanting less thought police and more freedom. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Community Team - where we want to go
On Mon, 11 Nov 2019, Gerardo Ballabio wrote: > That is, the team would rule on individual cases, rather than issuing > "lists of things not to do". IMHO that pretty much would make it a > court with the power to judge project members. And I'm not sure that > the team not taking actual measures, but just making "recommendations" > to other people who are empowered to take action, would make a > difference. In fact, that would be curiously similar to how the > Inquisition proceeded: technically they never executed anyone, they > just sent people to the secular authority with the "recommendation" to > burn them at the stake. > > And if the people empowered to take action can disagree with the > recommendation and apply their own judgement, well, that would make > the "ultimate authority" concept void, and I would say, would nullify > the whole point of having the team "interpret the CoC". +1 Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Community Team - where we want to go
Hi Steve, On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote: [...] > Responsibilities include > > > * Interpreting the Code of Conduct; I have to say that it was never my intention that there be one team that would have the power to "interpret" the Code of Conduct. It was carefully written to empower administrators of various systems in the project (i.e., IRC, mailinglists, salsa, etc) to "temporarily or permanently" ban people who use our systems in abusive ways, but with the caveat that the reasons for which that clause could be invoked are vague *on purpose*. The Code of Conduct tries to encourage good behavior, rather than discourage bad behavior, which makes for an easier way to detect that someone is breaking the rules set out in that document. There is a whole spectrum of different behaviors between what would be considered "good" and what would be considered "bad"; when someone does something that is "almost bad", then it is very obviously also "not good", so technically violating our Code of Conduct. With a Code of Conduct that enumerates bad behavior instead, we would (technically) have no reason to ban someone who is in the "almost bad" location for Code of Conduct violations. While I'm not arguing that we should take punitive action against everyone who violates our current Code of Conduct in the "almost bad" sense, there is a reason why it mentions "repeat offenders"; additionally, I also think that the current phrasing of the Code of Conduct allows administrators the necessary leeway to take the correct course of action as necessitated by individual situations. If what you mean by "interpreting" is "eventually come up with a long list of things not to do", then that would definitely be against the spirit of the current Code of Conduct (at least as it was intended by its primary author, i.e., me), and I would be disappointed if that were to happen. [...] > Examples of things the team does *not* do > = [...] > * Mediate communications or conversations between individuals; or I also wonder why you exclude this as a responsibility. I think that a team which does explicitly not have the power to take any punitive action (but at the same time is involved in a lot of situations like that) would often (though probably not always) be in an ideal position to mediate between members. What am I missing? -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Community Team - where we want to go
On Mon, Oct 21, 2019 at 07:37:16AM -0400, Sam Hartman wrote: > > * In extreme incidents or after repeated harmful behaviour or Code of > > Conduct violations, writing reports for relevant teams (e.g. Planet > > admins, listmasters, DAM), to summarise relevant incidents along > > with analysis and suggested possible courses of action; and > > my understanding from cambridge is that DAM would prefer not to get > recommendations on what to do in such cases. > Is DAM happy with the suggested possible courses of action language? > Even if not, it's fine to keep if other teams would appreciate that > feedback. Thanks, good catch! I would prefer to receive on the DAM side a collection or list of pointers to relevant things, and anything I could use to decide what to do, and I fear that receiving suggestions on what to do would make things more complicated. This is because if feel that if we receive a suggestion, not only we still need to figure out a course of action independently of what the reporter(s) suggests, but then we also need to deal with a conflict with the reporter(s) if the course of action that we choose is different from what was suggested. We might of course find it helpful or important, depending on cases, to reach out to the reporter(s) or other people involved to discuss possible course of actions. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
> "Holger" == Holger Levsen writes: Holger> Hi Sam, Holger> On Mon, Oct 21, 2019 at 09:34:25AM -0400, Sam Hartman wrote: >> >> 2) Choose to delegate. From my side the biggest question is Holger> could you please give a rough range for what 'enough people' Holger> would mean to you? Are 5 enough? 12? 23? 42? >> I'd prefer to toss that question to the Community team. Holger> Fair enough. >> I know they have given it some thought, and I haven't heard their >> most recent thoughts on the matter. Holger> TBH I'm still surprised you dont wanna give an answer on Holger> this, as you have identified this as your biggest question Holger> (so just must have a rough idea what 'enough' means in this Holger> context), probably even a blocker for delegation, while Holger> Sledge's mail doesn't mention this as an issue at all Holger> (though maybe it was such an obvious issue for them that Holger> they forgot to mention it). I would start by asking "Hey, do you think you have enough people?" Steve did talk about this at the DC19 BOF. I don't anticipate this being an issue where the community team and I would be very likely to disagree. --Sam
Re: Community Team - where we want to go
Hi Sam, On Mon, Oct 21, 2019 at 09:34:25AM -0400, Sam Hartman wrote: > >> 2) Choose to delegate. From my side the biggest question is > Holger> could you please give a rough range for what 'enough people' > Holger> would mean to you? Are 5 enough? 12? 23? 42? > I'd prefer to toss that question to the Community team. Fair enough. > I know they have given it some thought, and I haven't heard their most > recent thoughts on the matter. TBH I'm still surprised you dont wanna give an answer on this, as you have identified this as your biggest question (so just must have a rough idea what 'enough' means in this context), probably even a blocker for delegation, while Sledge's mail doesn't mention this as an issue at all (though maybe it was such an obvious issue for them that they forgot to mention it). I'm now even more curious what CT people will answer. and btw, there's no need to cc: me, I'm subscribed to the list. (As we are discussing the broader topic of CoC's here, I wish to point to #12 of https://www.debian.org/MailingLists/#codeofconduct and mention that I consider routinely ignoring it to be rather rude. Granted, I usually ignore such violations but it feels a bit absurd when discussing CoC topics.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Community Team - where we want to go
> "Holger" == Holger Levsen writes: Holger> Dear Sam, Holger> On Mon, Oct 21, 2019 at 07:37:16AM -0400, Sam Hartman wrote: >> 2) Choose to delegate. From my side the biggest question is >> likely to be whether you have managed to recruit enough people to >> [...] Holger> could you please give a rough range for what 'enough people' Holger> would mean to you? Are 5 enough? 12? 23? 42? I'd prefer to toss that question to the Community team. I know they have given it some thought, and I haven't heard their most recent thoughts on the matter. --Sam
Re: Community Team - where we want to go
Dear Sam, On Mon, Oct 21, 2019 at 07:37:16AM -0400, Sam Hartman wrote: > 2) Choose to delegate. From my side the biggest question is likely to > be whether you have managed to recruit enough people to [...] could you please give a rough range for what 'enough people' would mean to you? Are 5 enough? 12? 23? 42? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Community Team - where we want to go
Dear Steve: It sounds like the feedback you've received falls into a couple of categories: 1) Some minor tweaks, which you have responded to or are seeking more input on. Below the dashed line I have a couple of tweak/questions of my own. 2) A concern that the responsibilities you have described might better fit a delegated team than the current structure. In dealing with this concern, it sounds like you have two options. You can either try and split things into two parts. You can describe what you're doing now, and what you might want to do in the future. Alternatively, you can simply acknowledge that your description is more focused on an eventual goal. Honestly, I think the most critical success factor for the team is recruiting more people. I'd like to propose a recommendation. For now, focus on recruiting rather than on splitting your responsibilities/description into a now vs future split. Recruit assuming that you will eventually be delegated and that you will have responsibilities substantially similar to those you have outlined. Then say in early February we can revisit the delegation question. (February is probably the earliest slot in ongoing delegation work where we'd be able to bring the project-wide focus for the discussion) At that time we could: 1) Choose not to delegate at that point. If we make that choice it probably would be worth coming up with a split set of responsibilities (current vs future thinking) at that time. 2) Choose to delegate. From my side the biggest question is likely to be whether you have managed to recruit enough people to be responsive in the areas where the project has indicated being responsive is critical. 3) Do a phased delegation. So for example if you're still having trouble recruiting enough people, delegate some of the responsibilities including a significant focus on ongoing recruiting. How does that sound? I have two questions/concerns when I think about your description and compare it to past discussions and the mail I wrote last night: > * In extreme incidents or after repeated harmful behaviour or Code of > Conduct violations, writing reports for relevant teams (e.g. Planet > admins, listmasters, DAM), to summarise relevant incidents along > with analysis and suggested possible courses of action; and my understanding from cambridge is that DAM would prefer not to get recommendations on what to do in such cases. Is DAM happy with the suggested possible courses of action language? Even if not, it's fine to keep if other teams would appreciate that feedback. Under things the team does not do: > * Mediate communications or conversations between individuals; or Particularly in light of the de-escalation need I identified in my mail last night, I'd like to understand better what you mean by mediation. From past discussions it sounds like you definitely don't want to be involved in finding solutions to technical problems. You don't want to be doing the work for example I'm doing working with the elogind maintainers, systemd maintainers and others interested in init system issues. How do you feel about your interest and ability to step in and de-escalate situations? I'd be happy to give examples where that would have been useful in private mail to the team. At this stage, I just want to understand what you are willing/able to do and what you are not interested in. Thanks, --Sam signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Mon, Oct 14, 2019 at 01:40:34PM +0200, Enrico Zini wrote: > Posting draft team missions where one has to read between the lines > about possible institutional conflicts and other unsaid issues, is > emphatically /NOT/ a way to build trust within the project. To make it clear: I think the draft team mission that was posted is a great start for a discussion, and I think we need teams to support people in Debian, and I think we need a good way to escalate different interpretation of the CoC. What I think is not a way to build trust, is what Guillerme's reading of Tina's message was implying. I think those things hurt everyone and destroy good efforts, and I strongly wanted to push the discussion back to the idea of constucting something together. I see how my message could be read as implying that the whole draft Steve posted is not a good way to build trust. To the contrary, I consider it a good way to put cards on the table, and to start to work out together how they should be arranged. I was afraid I was hearing that some cards might not be kept on the table, and I wanted to strongly object to that. If all the cards are on the table, by all means, let's all find a good way to put them together! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Mon, 2019-10-14 at 13:40:34 +0200, Enrico Zini wrote: > On Sat, Oct 12, 2019 at 04:04:49AM +0200, Guillem Jover wrote: > > > Once you do that I'll be happy to work with you just as I would any > > > other group approaching changing/renewing/creating a delegation. > [...] > > But then I see no reason at all why they need to do that now. Even though > > they have already stated so, and the mail you reply to went as far as > > mentioning a timetable of around 12 months, which TBH I pretty much > > interpreted as a tactful way to say “once the current DPL term is over”. > > If one wants a delegation from a DPL, I'd expect them to work *with* the > DPL, as the DPL is the person responsible for delegations. With *a* DPL, certainly. But the project is conformed of people, not abstract titles, groups and teams. Iff, say, some people cannot work together, then I'm not sure why it would be more desirable to make a huge mess out of that, instead of trying to work with someone else. Time also tends to let things cool down. > If a team has an issue with a DPL, I expect them to acknowledge the > issue, state their long term plans and why they wouldn't work with the > current DPL, state what they'd like to do in an interim situation, > propose a GR. > > Posting draft team missions where one has to read between the lines > about possible institutional conflicts and other unsaid issues, is > emphatically /NOT/ a way to build trust within the project. That's the ideal, yes, but it also only works when such possible issues can actually be discussed in _public_, while not being bound by externally imposed non-leak restrictions… Bringing up GRs here, seems to me to be the opposite of trying to make Debian a more pleasant environment, though. > I think the responsibility of interpreting the CoC should go to people > who we can trust not to wield it like a club, who are clearly named, and > so on. A delegation provides this. And I think they made it pretty clear already, that they were ever only considering assuming that (exclusive) responsibility, once and *iff* the team becomes delegated… > Currently, as I understand it, interpretation of the CoC is the > responsibility of the DPL, overridable by GR. Needing to read between > the lines of a proposal like this, instantly makes me think of attempts > to grab that power away from the DPL. Of trying to force a self-written > delegation on the first DPL who gets distracted for a moment. This is > most emphatically /NOT/ a way to build trust within the project. > > I have seen, in other communities, successful power grabbing attempts > done by emptional blackmail, refusals to take no for an answer, and > similar kinds of social pressure. I don't at all mean to imply that it > is what is happening here, and I trust at least some of the member of > the (AH|Community) team enough to believe it is actually not the case. But you still brought all this up. :/ > Still, I most emphatically do not want to have to read things between > the lines in a discussion like this one. Not when power is involved. Not > when trust is involved. Sorry, but this characterization seems rather unfair, when it seems to me to be the reaction of just trying to work with the restrictions imposed by previous events, characterized precisely by the thing you are criticizing in this exact paragraph. Regards, Guillem
Re: Community Team - where we want to go
On Sat, Oct 12, 2019 at 04:04:49AM +0200, Guillem Jover wrote: > > Once you do that I'll be happy to work with you just as I would any > > other group approaching changing/renewing/creating a delegation. [...] > But then I see no reason at all why they need to do that now. Even though > they have already stated so, and the mail you reply to went as far as > mentioning a timetable of around 12 months, which TBH I pretty much > interpreted as a tactful way to say “once the current DPL term is over”. If one wants a delegation from a DPL, I'd expect them to work *with* the DPL, as the DPL is the person responsible for delegations. If a team has an issue with a DPL, I expect them to acknowledge the issue, state their long term plans and why they wouldn't work with the current DPL, state what they'd like to do in an interim situation, propose a GR. Posting draft team missions where one has to read between the lines about possible institutional conflicts and other unsaid issues, is emphatically /NOT/ a way to build trust within the project. I think the responsibility of interpreting the CoC should go to people who we can trust not to wield it like a club, who are clearly named, and so on. A delegation provides this. Currently, as I understand it, interpretation of the CoC is the responsibility of the DPL, overridable by GR. Needing to read between the lines of a proposal like this, instantly makes me think of attempts to grab that power away from the DPL. Of trying to force a self-written delegation on the first DPL who gets distracted for a moment. This is most emphatically /NOT/ a way to build trust within the project. I have seen, in other communities, successful power grabbing attempts done by emptional blackmail, refusals to take no for an answer, and similar kinds of social pressure. I don't at all mean to imply that it is what is happening here, and I trust at least some of the member of the (AH|Community) team enough to believe it is actually not the case. Still, I most emphatically do not want to have to read things between the lines in a discussion like this one. Not when power is involved. Not when trust is involved. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Fri, 2019-10-11 at 07:27:30 -0400, Sam Hartman wrote: > > "Martina" == Martina Ferrari writes: > Martina> The main conclusion from that is that yes, some of things > Martina> expressed in the proposal require a delegation, I agree! > Martina> Perhaps, the disconnection lies in reading that the team > Martina> does not want to be delegated: quite the opposite, at least > Martina> from my part! I had been in talks with the previous DPL > Martina> about delegation since last year, but the burnout caused by > Martina> the events around December and January delayed progress and > Martina> then there was a DPL change, so we had to start from > Martina> scratch and with considerably less support. > I think the process we use is different depending on which direction > we're going to go. I agree as other people have voiced, that it should be made more clear what are the things that are expected/desired to be part of a future delegation, and what are the things that are going to be part of the team operation while that is not the case yet. > […] They drive the question of whether we have > the right team description and whether we have the right people for the > job. Aha. > So if the intent is to move toward delegation, say that as a team now, > not later. > > Once you do that I'll be happy to work with you just as I would any > other group approaching changing/renewing/creating a delegation. This demand makes this interaction rather awkward, :/ given the context this is in, and which we cannot discuss in here, and which might require spelling out what I'll mention in the next paragraph, which I think should have been no need to. :( But then I see no reason at all why they need to do that now. Even though they have already stated so, and the mail you reply to went as far as mentioning a timetable of around 12 months, which TBH I pretty much interpreted as a tactful way to say “once the current DPL term is over”. Regards, Guillem
Re: Community Team - where we want to go
Thanks for all the feedback already, folks - it's really appreciated! Several of you have expressed reasonable concerns about a non-delegated team of people setting themselves up as interpreters of the CoC, and that's totally understandable. We *have* been applying our own ideas about the CoC already, but so do many others in day-to-day interactions. We see a wider role, though. What we're definitely hoping to get to at some point is a delegation from the DPL here. We know that we'll have to build trust with the DPL, the project and the wider community to get there. Part of that starts here: we want to openly talk about the role and responsibilities that we see for the team now and in the future. Apologies if I wasn't clear enough in explaining this up-front! :-/ Now, responding to some of the individual points directly. This is quite long, but I'd rather respond to grouped things together than spam the list N times here. I hope I've responded to people's points reasonably in this summary; If you think otherwise then please point it out. On Thu, Oct 10, 2019 at 10:08:55AM +0200, Mathias Behrle wrote: >* Steve McIntyre: " Community Team - where we want to go" (Wed, 9 Oct 2019 > 22:26:39 +0100): >> >> * Proactively writing emails to those who habitually make the >>community a hostile place, informing them that their behavior is >>harmful to the community, that action may be taken in the future, >>and that the Community team is a resource to provide explanation or >>guidance. > >What does mean "that action may be taken in the future"? Which actions in which >context does the team want to perform? Is this a pure informal step about >actions of other teams? I think the following negative list is not the way to >go, but a clear statement should be made. As Martina explained - we don't expect nor want powers to take direct action if people are disruptive and not following the CoC. What we will do is try and warn people that we think they are not behaving according to our agreed standards and (*importantly*) give suggestions on how they might improve. If that doesn't work, we will share our feelings with those teams in Debian that do have powers: listmaster, Planet admins, maybe DAM in extremis. This is a perfect example: On Thu, Oct 10, 2019 at 11:57:21AM +0200, Gerardo Ballabio wrote: >Enrico Zini wrote: >>> * Remove blogs from community forums like Planet Debian >> >>This I think is something the team could actually do, just as any Debian >>Developer could do it, having commit access to the planet config. > >While technically they have the ability to do that, they are not >allowed to. Reading from >https://wiki.debian.org/PlanetDebian#How_do_I_add_myself_to_Planet.3F >: > >"Any contributor may add, amend or remove *their own* blog entry from >Planet Debian." (emphasis in the original text) > >I.e., they may not remove other people's blog. Only Planet admins can do that. ACK - we'd instead talk to Planet admins to share concerns if needs be. On Thu, Oct 10, 2019 at 11:00:43AM +0200, Gerardo Ballabio wrote: >Steve McIntyre wrote: >> Within the team, we've brainstormed about this and come up with the >> following to describe our role and responsibilities. We'd like to >> discuss it now wit h the rest of the project. Feedback welcome >> please! > >that looks good (I especially like the "Examples of things the team >does *not* do"), but I think you should also add something on how the >team will be handling confidential information that it's going to have >access to as part of its job. > >I suppose it won't be easy to strike a good balance between the right >to privacy, the right of accused people to know what they're accused >of and by whom and to defend themselves, the right of victims to not >having to confront their abusers, and so on. So this deserves to be >thought through carefully and clear guidelines should be set. Agreed. It's not an easy situation. We've already been talking to the privacy team to get advice on sensible ways to do this. We will describe our workflow and guidelines more fully as that comes to fruition. On Thu, Oct 10, 2019 at 09:18:07PM +0900, Charles Plessy wrote: >Le Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre a écrit : >> >> The (CT) is the team responsible for interpreting the Code of Conduct >> (CoC) when necessary. > >Like others and for the same reasons, I think that to be responsible for >interpretation it would necessitate a delegation. I would like to add >if you follow that direction, then it would be better that the team does >not take responsabilities such as judging the behaviour of others, that >would lead it to be both raising a question of interpretation and giving >an authoritative answer at the same time. I've had similar feedback privately from somebody else, and I understand the idea. My main worry with separation like this is finding yet more volunteers to do two jobs rather then the one we envisage. In the vast
Re: Community Team - where we want to go
Hello Martina, On Fri 11 Oct 2019 at 04:56AM +01, Martina Ferrari wrote: > On 10/10/2019 10:16, Enrico Zini wrote: >> I suggest to review your notes with the idea that there could be two >> or more such teams in Debian posting the same set of notes, and they >> shouldn't conflict. > > I don't think that would be a good use of anybody's time. The CT wants > to be *the* team doing the proposed job, and it would be kind of silly > to have two teams doing the exact same thing. If there is another team > that the project feels more fit for the job, then the CT should disband. I don't think Enrico is suggesting that there actually be two teams. I could be wrong, but I think his point was that unless you're seeking a delegation, it would useful to imagine that there *could* be another team, while reviewing your own proposals. That way, you can ensure that they really are reasonable proposals for a non-delegated entity. On Fri 11 Oct 2019 at 07:27AM -04, Sam Hartman wrote: > If you're going down the delegation path, it is good to decide that > early. That way we know that the project feedback matters in a > different way than if it is a non-delegated entity just soliciting > feedback on how they can be useful. Right. I believe that Enrico's suggestion, quoted above, applies to the case in which a non-delegated entity is seeking feedback. -- Sean Whitton signature.asc Description: PGP signature
Re: Community Team - where we want to go
TL;DR: I think delegating the community team would be great; if that's their desire let's work toward that. > "Martina" == Martina Ferrari writes: Martina> The main conclusion from that is that yes, some of things Martina> expressed in the proposal require a delegation, I agree! Martina> Perhaps, the disconnection lies in reading that the team Martina> does not want to be delegated: quite the opposite, at least Martina> from my part! I had been in talks with the previous DPL Martina> about delegation since last year, but the burnout caused by Martina> the events around December and January delayed progress and Martina> then there was a DPL change, so we had to start from Martina> scratch and with considerably less support. I think we may be talking past each other. I strongly support the idea of delegating the community team. I think the process we use is different depending on which direction we're going to go. In particular, I think even at this stage how we approach things depends on whether we're on a delegation path or not. If we're on a delegation path, the critical question is what are the project needs in this area. They drive the question of whether we have the right team description and whether we have the right people for the job. If you're a group of developers, the key factor is what work you want to do. Yes, even for a delegation it's important that the delegates want to do the job, and yes, that influences the task description a lot. But ultimately, the delegates serve the needs of the project in a way that is not true for a non-delegated entity. That service is the presponsibility that justifies the power of a delegation. If you're going down the delegation path, it is good to decide that early. That way we know that the project feedback matters in a different way than if it is a non-delegated entity just soliciting feedback on how they can be useful. That way we're considering both the delegates and the task rather than just what a team wants to do. So if the intent is to move toward delegation, say that as a team now, not later. Once you do that I'll be happy to work with you just as I would any other group approaching changing/renewing/creating a delegation. --Sam
Re: Community Team - where we want to go
Hi, Responding here on individual capacity, and my team mates will surely have different views on some items. I will try to address some of the comments and criticisms of our proposal at once. First of all, I think that we did not make it clear enough that this is "where we want to go", as the subject line reads. We're not there, but we want to work towards this goal. The main conclusion from that is that yes, some of things expressed in the proposal require a delegation, I agree! Perhaps, the disconnection lies in reading that the team does not want to be delegated: quite the opposite, at least from my part! I had been in talks with the previous DPL about delegation since last year, but the burnout caused by the events around December and January delayed progress and then there was a DPL change, so we had to start from scratch and with considerably less support. My view of this discussion is to try to reach consensus on what the CT role should be when a delegation comes, work towards fulfilling that role (without the powers and formalisation that delegation would provide), and finally obtain a delegation when the DPL agrees the team is ready. I believe we could finish this process within the next 12 months. Many of the concerns raised were about wording and implication of powers not yet granted by a delegation, so I will not address those individually. On 10/10/2019 09:08, Mathias Behrle wrote: > For me it is beyond the tasks of the team to *ensure* the > observation of the CoC on Debian events. This sounds again like an > official assignment that in reality doesn't exist. Leaving aside the fact that the wording will be contingent on a delegation, the team has already been liaising with DebConf (and other-conf) organisers for a number of years to set-up incident response teams and to communicate to the community that there is a CoC in effect and that there are people to help when it is broken. >> * Proactively writing emails to those who habitually make the >>community a hostile place, informing them that their behavior is >>harmful to the community, that action may be taken in the future, >>and that the Community team is a resource to provide explanation or >>guidance. > What does mean "that action may be taken in the future"? Which > actions in which > context does the team want to perform? Is this a pure informal step > about actions of other teams? I think the following negative list is > not the way to > go, but a clear statement should be made. This needs to be clarified, yes. That means that the CT might issue warnings, and finally escalate to other teams that might apply sanctions at their discretion. On 10/10/2019 13:18, Charles Plessy wrote: >> The (CT) is the team responsible for interpreting the Code of Conduct >> (CoC) when necessary. > Like others and for the same reasons, I think that to be responsible > for interpretation it would necessitate a delegation. I would like > to add if you follow that direction, then it would be better that the > team does not take responsabilities such as judging the behaviour of > others, that would lead it to be both raising a question of > interpretation and giving an authoritative answer at the same time. Absolutely. The proposal is for DAM, listmaster, etc to be the final judges on whether somebody has crossed a line serious enough. >> Where desired, the team will work with contributors to help them >> express disagreement without violating the CoC. > > I think that providing behavioural guidance is an excellent goal. > However I think that it will be more effective by addressing the > community in general. To be frank, I do not have the impression that > the people who usually express themselves "bluntly" will actively seek > your advice. We try to do that, as it is a more efficient use of our resources, but it is not always possible. About your second sentence, you would be surprised: sometimes people do want to improve and be better colleagues, and I can see the work they put. > I also feel that it is important that people are being explained when > they hurt others. But I have one comment and one question: > > - Given what happened in the past, I think that it is crucial that >there is a crystal clear difference between being given guidance and >being given a warning. For instance, it could be that any message >from the CT is not a warning unless stated otherwise. Agreed. > - I think that it is bound to happen that one day, a message of >guidance will be badly received, and will lead the receiver to behave >worse than if they did not get a message. What is your plan in that >case ? This is not theoretical, it happens whether at the guidance or at the warning level, and the strategy is always to try to de-escalate, until is time to raise the issue to other teams. >> * Responding in a timely manner to incidents reported by members of >>the Debian community and those
Re: Community Team - where we want to go
A community team is a good thing. Just its apparent focus on the Code of Conduct is unfortunate. The biggest modulators of how we interact among ourselves and how much inviting we are perceived as a community imho currently are (somewhat ordered): * salsa * blends * debconfs * sprints * patches by .deb maintainers on github/bitbucket/... * news on Debian being adopted by some 3rd party for something fancy * our discussion on the mailing lists And I want more of that. I wish the Community Team comes up with new ideas that are all positively minded. The CoC is somewhere out there but luckily not omnipresent. I have some confidence that no (zero) DM/DD enjoys to be meeting regularly in some group to discuss that CoC and its application ... this is just nothing why we are here. And consequently DDs distrust other DDs that volunteer to be on such a team. So, have your Meta Team and talk about how to evolve our togetherness. That shall involve having an eye on that we are no intentionally or unintentionally hurting each other in our communication but should by no means dominate what that team is about. Best, Steffen
Re: Community Team - where we want to go
On 09/10/19 at 22:26 +0100, Steve McIntyre wrote: > * Proactively writing emails to those who habitually make the >community a hostile place, informing them that their behavior is >harmful to the community, that action may be taken in the future, ^ that sounds a bit strange given the team doesn't really have the power to take actions itself, but I can live with that. How official is this group? If it is not delegated, should it be listed (for example on https://www.debian.org/intro/organization.en.html) as an official contact point? (I believe it should not) Lucas
Re: Community Team - where we want to go
On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote: > Hi folks, > > We've had a lot of conversations this year about where the > Anti-Harassment (now *Community*) Team should be going: what we're > trying to do, and the relationship we'd like to have with the rest of > the project and the wider community. > > Within the team, we've brainstormed about this and come up with the > following to describe our role and responsibilities. We'd like to > discuss it now with the rest of the project. Feedback welcome please! > > Name: Community Team > > > Role > > > The goal of the Community Team (CT) is to help Debian be a welcoming > place, focusing on response to difficult or contentious > communications, as well as other negative experiences and Code of > Conduct violations. It aims to encourage and foster a respectful, > productive, and inclusive atmosphere throughout the Debian community. > > The team itself has no direct powers to enforce any decision, and > merely acts as an advisory body. It will aim to respond in a timely > matter when consulted, and to do so in a consistent way. The (CT) is > the team responsible for interpreting the Code of Conduct (CoC) when > necessary. Hello, I have to object strongly to the last point. As you have stated above, the CT is a self-appointed group of DDs and insofar by definition has no more powers within the project than any other random group of DDs, so there is no way that the CT could be responsible for and thereby have the power to decide over the interpretation of the CoC in cases where such an interpretation is contentious within the project. > We break this down in more concrete terms: > > Responsibilities include > > > * Interpreting the Code of Conduct; > > * Responding in a timely manner to incidents reported by members of >the Debian community and those interacting with the Debian project; > > * Contacting individual contributors about their behavior when it is >considered to be in violation of the Debian Code of Conduct; > > * Providing support and guidance for event incident response teams; > > * Offering advice and guidance for policies and implementation around >community standards and guidelines; > > * Being available as a resource for those looking for content review >of communications or who have questions about how possible actions >may fit with the Code of Conduct; > > * In extreme incidents or after repeated harmful behaviour or Code of >Conduct violations, writing reports for relevant teams (e.g. Planet >admins, listmasters, DAM), to summarise relevant incidents along >with analysis and suggested possible courses of action; and I have to object to the term "responsibilities" again here. "Having the responsibility" implies a power to do so in a way that is different from the power of any other project member. Members of the CT are of course free to perform any of the actions listed above in the same way that any other project member is free to perform them, but the CT is no more and no less "responsible" for them than any other random DD, and if members of the CT perform any of those actions they must not be given any more or any less weight than the same action by any other DD. Regards, Karsten -- Ich widerspreche hiermit ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Re: Community Team - where we want to go
[content summary: interpretation with delegation, role separation for definition and enforcement of rules, distinction between guidance and warning, timeliness.] Hi Steve, Community team and everybody, I think that the current changes in name and role of the A-H team go in a good direction. Here are some comments that I hope are in line with and will help your efforts. Le Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre a écrit : > > The (CT) is the team responsible for interpreting the Code of Conduct > (CoC) when necessary. Like others and for the same reasons, I think that to be responsible for interpretation it would necessitate a delegation. I would like to add if you follow that direction, then it would be better that the team does not take responsabilities such as judging the behaviour of others, that would lead it to be both raising a question of interpretation and giving an authoritative answer at the same time. > Where desired, the team will work with contributors to help them > express disagreement without violating the CoC. I think that providing behavioural guidance is an excellent goal. However I think that it will be more effective by addressing the community in general. To be frank, I do not have the impression that the people who usually express themselves "bluntly" will actively seek your advice. > When people do breach the CoC, the team will give guidance on better > ways to interact in the future. I also feel that it is important that people are being explained when they hurt others. But I have one comment and one question: - Given what happened in the past, I think that it is crucial that there is a crystal clear difference between being given guidance and being given a warning. For instance, it could be that any message from the CT is not a warning unless stated otherwise. - I think that it is bound to happen that one day, a message of guidance will be badly received, and will lead the receiver to behave worse than if they did not get a message. What is your plan in that case ? > * Responding in a timely manner to incidents reported by members of >the Debian community and those interacting with the Debian project; This timeliness is extremely important and I think that it is great that you mentionned it. In case of overload, I think that timeliness should be given priority over exhaustiveness. That is: drop the less grave cases if there is no time to respond to all at the same time. > * Where there might be a Conflict of Interest, individual members of >the team will be expected to inform the rest of the team, about it >and recuse themselves from relevant discussion. Thanks for including that point. > * Writing and providing reports to other teams concerning incidents >or habitual behaviors; and Given what happened in the past, I think that it would be important to put a clear limit on how far in the past the behaviour of people will be investigated, and how behavioural patterns will or will not be aggregated. Timely and focused reaction will reduce contention. > * Proactively writing emails to those who habitually make the >community a hostile place, informing them that their behavior is >harmful to the community, that action may be taken in the future, >and that the Community team is a resource to provide explanation or >guidance. This implies that the CT will contact these people when it is available to answer in a timely manner to their rebuttals, which is great, Have a nice day, and thanks for your work on the reboot of the team ! Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Community Team - where we want to go
> "Enrico" == Enrico Zini writes: Enrico> On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote: Enrico> I join other respondents, with a risk of redundancy, with a Enrico> few notes due to the decision of not having delegated powers Enrico> and being an undelegated advisory group. >> The (CT) is the team responsible for interpreting the Code of >> Conduct (CoC) when necessary. Enrico> I feel strongly against this: "The team" hints at being the Enrico> only team, and "Responsible" hints at having power. Enrico> I believe strongly that anyone who is /the/ person/team Enrico> responsible for interpreting the Code of Conduct needs to Enrico> gain that responsibility from an official delegation, and Enrico> absent a delegation, I believe that the only person Enrico> ultimately responsible for interpreting the CoC when Enrico> necessary is the DPL, overridable by a GR. Enrico> However, I also believe that any member of the Debian Enrico> community is responsible for upholding the Code of Conduct, Enrico> and I'm fine with the idea that one or more people or groups Enrico> could make themselves available to help with CoC Enrico> interpretation or supporting people if things get heated. I strongly support the above. It's going to be a day or two before I get a chance to comment on the team's proposal. I think that interpreting the CoC is something that requires a delegation. I think that ultimately the project could use interpretation of the CoC in some cases, and that eventually a delegated community team will be something the project needs. >> Finally, the CT will also work in combination with event >> organisers to deploy incident response teams on the ground and >> ensure that the CoC is observed for Debian events. Enrico> In the same light as above, I suggest s/work/make itself Enrico> available/, as any other group could make themselves Enrico> available to event organisers to help with Debian or Enrico> event-specific CoC. This is an area where I actually think the project needs a single delegated entity to coordinate IRTs with events. I agree with Enrico that being *the entity* is not something that an individual group of developers can do. But I think that there are significant advantages in having project-wide consistency in how we approach IRTs and to do that, I think a delegation would be necessary. Enrico> Some more general feedback points. Enrico> I suggest to review your notes with the idea that there Enrico> could be two or more such teams in Debian posting the same Enrico> set of notes, and they shouldn't conflict. Enrico> Also, given the idea that there can be multiple groups doing Enrico> this, the name "Community Team" sounds possibly problematic Enrico> name to me, as it hints indeed at being /the/ team for Enrico> Debian Community issues, which could potentially be setting Enrico> the wrong kinds of expectations. Enrico> Although I would prefer a name that would make it explicit Enrico> that we're talking about /a/ /self-appointed/ group, I Enrico> wouldn't consider the naming a blocker: I know names are Enrico> hard, and I don't want you all to spend your energy picking Enrico> names. Enrico> Still, I'd acknowledge and keep in mind that the name does Enrico> sound ambitious, and as a consequence I'd expect you all to Enrico> be extremely careful in all team descriptions and team Enrico> actions to make it clear that you are /a/ community team, Enrico> not /the/ community team. Enrico> Enrico Enrico> -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini Enrico>
Re: Community Team - where we want to go
On October 10, 2019 9:00:43 AM UTC, Gerardo Ballabio wrote: >Steve McIntyre wrote: >> Within the team, we've brainstormed about this and come up with the >following to describe our role and responsibilities. We'd like to >discuss it now with the rest of the project. Feedback welcome please! > >Hi Steve, >that looks good (I especially like the "Examples of things the team >does *not* do"), but I think you should also add something on how the >team will be handling confidential information that it's going to have >access to as part of its job. > >I suppose it won't be easy to strike a good balance between the right >to privacy, the right of accused people to know what they're accused >of and by whom and to defend themselves, the right of victims to not >having to confront their abusers, and so on. So this deserves to be >thought through carefully and clear guidelines should be set. > >Scott Kitterman wrote: >> From what does the team believe they derive their authority to do >things like interpret the CoC and to whom is the team accountable? > >Norbert Preining wrote: >> As "just another group of Debian Developers" I am not sure how you >can usurp the right to exegesis of the CoC? > >My understanding is that the team is expecting to receive a formal >delegation from the DPL which would give them such authority. Given >also that they are going to handle confidential information (see >above), my opinion is that a delegation is indeed necessary. What's the basis for this understanding? I've not seen anything discussed to that effect, in fact the last time this came up (that I'm aware of) there was substantial push back from the team on the idea? >However, I'd also observe that it's quite common in Debian for people >to take over a specific responsibility and be granted a de facto >"monopoly" over it without a formal delegation. For example, >maintainers take ownership of their packages without being delegated, >yet everybody accepts that it is a very bad thing to act on a package >against the maintainer's will. That isn't really different from the >Community Team claiming ownership of interpreting the CoC simply >because they were the first who started working on that. I think you inadvertently make my point for me. The maintainer role is defined in Debian policy and the tech-ctte had a constitutionally defined responsibility to decide who the maintainer is in case of disputes. Yes, one can volunteer to be a package maintainer for a particular package, but the role and it's oversight are well documented by the project. There's nothing self-defined about it. Scott K
Re: Community Team - where we want to go
I wrote: > That isn't really different from the Community Team claiming ownership of > interpreting the CoC simply because they were the first who started working > on that. Thinking again about it, maybe they should have filed an ITP bug?!? Gerardo
Re: Community Team - where we want to go
Enrico Zini wrote: >> * Remove blogs from community forums like Planet Debian > >This I think is something the team could actually do, just as any Debian >Developer could do it, having commit access to the planet config. While technically they have the ability to do that, they are not allowed to. Reading from https://wiki.debian.org/PlanetDebian#How_do_I_add_myself_to_Planet.3F : "Any contributor may add, amend or remove *their own* blog entry from Planet Debian." (emphasis in the original text) I.e., they may not remove other people's blog. Only Planet admins can do that. Gerardo
Re: Community Team - where we want to go
Steve McIntyre wrote: > Within the team, we've brainstormed about this and come up with the following > to describe our role and responsibilities. We'd like to discuss it now with > the rest of the project. Feedback welcome please! Hi Steve, that looks good (I especially like the "Examples of things the team does *not* do"), but I think you should also add something on how the team will be handling confidential information that it's going to have access to as part of its job. I suppose it won't be easy to strike a good balance between the right to privacy, the right of accused people to know what they're accused of and by whom and to defend themselves, the right of victims to not having to confront their abusers, and so on. So this deserves to be thought through carefully and clear guidelines should be set. Scott Kitterman wrote: > From what does the team believe they derive their authority to do things like > interpret the CoC and to whom is the team accountable? Norbert Preining wrote: > As "just another group of Debian Developers" I am not sure how you can usurp > the right to exegesis of the CoC? My understanding is that the team is expecting to receive a formal delegation from the DPL which would give them such authority. Given also that they are going to handle confidential information (see above), my opinion is that a delegation is indeed necessary. However, I'd also observe that it's quite common in Debian for people to take over a specific responsibility and be granted a de facto "monopoly" over it without a formal delegation. For example, maintainers take ownership of their packages without being delegated, yet everybody accepts that it is a very bad thing to act on a package against the maintainer's will. That isn't really different from the Community Team claiming ownership of interpreting the CoC simply because they were the first who started working on that. Gerardo
Re: Community Team - where we want to go
On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote: I join other respondents, with a risk of redundancy, with a few notes due to the decision of not having delegated powers and being an undelegated advisory group. > The (CT) is the team responsible for interpreting the Code of Conduct > (CoC) when necessary. I feel strongly against this: "The team" hints at being the only team, and "Responsible" hints at having power. I believe strongly that anyone who is /the/ person/team responsible for interpreting the Code of Conduct needs to gain that responsibility from an official delegation, and absent a delegation, I believe that the only person ultimately responsible for interpreting the CoC when necessary is the DPL, overridable by a GR. However, I also believe that any member of the Debian community is responsible for upholding the Code of Conduct, and I'm fine with the idea that one or more people or groups could make themselves available to help with CoC interpretation or supporting people if things get heated. At that point, however, the CoC interpretation is not a responsibility but an offer of help, whose value can maybe come from experience and reputation of a person or team members inside the project. > Finally, the CT will also work in combination with event organisers to > deploy incident response teams on the ground and ensure that the CoC > is observed for Debian events. In the same light as above, I suggest s/work/make itself available/, as any other group could make themselves available to event organisers to help with Debian or event-specific CoC. > Responsibilities include > I agree with what Mathias Behrle wrote about this session. > Examples of things the team does *not* do > = > > * Remove blogs from community forums like Planet Debian This I think is something the team could actually do, just as any Debian Developer could do it, having commit access to the planet config. > * Take punitive measures or actions against members of the Community. I find this point a bit tricky, because I think that what is "punitive" is up for subjective interpretation. For example, feeling forced to engage with individuals wearing a Community Team badge could already be seen by some as a punitive measure. You may want to remove this point entirely, as it's mostly covered by the other examples of what the team does not do. - - - Some more general feedback points. I suggest to review your notes with the idea that there could be two or more such teams in Debian posting the same set of notes, and they shouldn't conflict. Also, given the idea that there can be multiple groups doing this, the name "Community Team" sounds possibly problematic name to me, as it hints indeed at being /the/ team for Debian Community issues, which could potentially be setting the wrong kinds of expectations. Although I would prefer a name that would make it explicit that we're talking about /a/ /self-appointed/ group, I wouldn't consider the naming a blocker: I know names are hard, and I don't want you all to spend your energy picking names. Still, I'd acknowledge and keep in mind that the name does sound ambitious, and as a consequence I'd expect you all to be extremely careful in all team descriptions and team actions to make it clear that you are /a/ community team, not /the/ community team. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
* Steve McIntyre: " Community Team - where we want to go" (Wed, 9 Oct 2019 22:26:39 +0100): Hi! > Within the team, we've brainstormed about this and come up with the > following to describe our role and responsibilities. We'd like to > discuss it now with the rest of the project. Feedback welcome please! Like others I have some concerns whenever it comes to "responsibilities". I would feel a lot more comfortable if this term could be replaced by "team agenda". > Name: Community Team > > > Role > > > The goal of the Community Team (CT) is to help Debian be a welcoming > place, focusing on response to difficult or contentious > communications, as well as other negative experiences and Code of > Conduct violations. It aims to encourage and foster a respectful, > productive, and inclusive atmosphere throughout the Debian community. > > The team itself has no direct powers to enforce any decision, and > merely acts as an advisory body. It will aim to respond in a timely > matter when consulted, and to do so in a consistent way. The (CT) is > the team responsible for interpreting the Code of Conduct (CoC) when > necessary. This sounds like the team would represent the last resort when it comes to interpretation of the CoC. In my understanding the interpretation of the CoC may be an important tool for the work inside the team, but there is in no way a project wide responsibility assigned. > The team will respond to concerns raised by members of the project or > people interacting with them, working with individuals to help > them. The team recognises that technical development can lead to > arguments and passionate discussions. Where desired, the team will > work with contributors to help them express disagreement without > violating the CoC. When people do breach the CoC, the team will give > guidance on better ways to interact in the future. We will attempt to > consult with those on all sides of issues when possible. Nevertheless, > protection of the vulnerable and the community as a whole is the > ultimate goal of the team. > > If things do not work out, and in cases with a pattern of repeating > problems, the team will raise concerns with other teams as > appropriate. > > Members of the community should feel empowered to seek counsel when > they have doubts about the CoC, or when they feel it is being > violated. The team normally acts reactively, but might also try to > intervene when individual members witness a problematic situation. > > Finally, the CT will also work in combination with event organisers to > deploy incident response teams on the ground and ensure that the CoC > is observed for Debian events. For me it is beyond the tasks of the team to *ensure* the observation of the CoC on Debian events. This sounds again like an official assignment that in reality doesn't exist. > We break this down in more concrete terms: > > Responsibilities include > Please make this unambigous. From what I see (I am not a native speaker) the term "responsibility" comprises a wide spectrum of meanings like: accountability, liability, charge, ownership, stewardship, duty, obligation, business, etc.. I would personally feel much better with a term like 'self identified tasks of the team'. > * Interpreting the Code of Conduct; > > * Responding in a timely manner to incidents reported by members of >the Debian community and those interacting with the Debian project; > > * Contacting individual contributors about their behavior when it is >considered to be in violation of the Debian Code of Conduct; > > * Providing support and guidance for event incident response teams; > > * Offering advice and guidance for policies and implementation around >community standards and guidelines; > > * Being available as a resource for those looking for content review >of communications or who have questions about how possible actions >may fit with the Code of Conduct; > > * In extreme incidents or after repeated harmful behaviour or Code of >Conduct violations, writing reports for relevant teams (e.g. Planet >admins, listmasters, DAM), to summarise relevant incidents along >with analysis and suggested possible courses of action; and > > * Where there might be a Conflict of Interest, individual members of >the team will be expected to inform the rest of the team, about it >and recuse themselves from relevant discussion. > > Examples of team activities > === > > * Releasing regular reports on incidents reported and the responses >of the team; > > * Providing recommendations on communications when recommendations >are sought by members of the community; > > * Quick response time alerting reporters that action might be taken; > > * Holding regular meetings (and emergency meetings, when relevant), >to discuss incidents reported and actions to be taken; > > * Writing and
Re: Community Team - where we want to go
On Wednesday, October 9, 2019 5:26:39 PM EDT Steve McIntyre wrote: > Hi folks, > > We've had a lot of conversations this year about where the > Anti-Harassment (now *Community*) Team should be going: what we're > trying to do, and the relationship we'd like to have with the rest of > the project and the wider community. > > Within the team, we've brainstormed about this and come up with the > following to describe our role and responsibilities. We'd like to > discuss it now with the rest of the project. Feedback welcome please! >From what does the team believe they derive their authority to do things like interpret the CoC and to whom is the team accountable? Scott K
Re: Community Team - where we want to go
On 2019/10/10 02:40, Norbert Preining wrote: > As "just another group of Debian Developers" I am not sure how you can > usurp the right to exegesis of the CoC? What about if another group XYZ > (like the Debian TeX Team) decides that our responsability is > Interpreting the Code of Conduct Yep, any group in Debian can read and interpret the Debian CoC, likely, probably anyone who ever reads it might have their own interpretation of the CoC. What the community team is effectively doing here is just offering a service to do so, they're not imposing an authority of how every CoC violation should be handled. Instead, if you as part of any leadership role in Debian (maybe the DPL, maybe a member of a team) are seeking some feedback, you can use the community team as a sounding board to get their view on it. At least, that's my understanding. > Same old wine in new bottles ... Some wine'ing has gotten old a really long time ago. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Community Team - where we want to go
Hi On Wed, 09 Oct 2019, Steve McIntyre wrote: > Name: Community Team > The team itself has no direct powers to enforce any decision, and > merely acts as an advisory body. It will aim to respond in a timely > Responsibilities include > * Interpreting the Code of Conduct; As "just another group of Debian Developers" I am not sure how you can usurp the right to exegesis of the CoC? What about if another group XYZ (like the Debian TeX Team) decides that our responsability is Interpreting the Code of Conduct ? Same old people under new name ... Same old wine in new bottles ... Nothing has changed. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
