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
