[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft Delegation for the Community Team



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/04/2020 22:40, Sam Hartman wrote:> I'm pleased to finally be
able to propose a Community Team delegation
> for discussion.  During the last year it has become clear that we
> can accomplish more at lower emotional cost when we have the
> Community Team, Account Managers and DPL working together,
> supporting each other.  It's become clear that the Community Team
> does need a project-level mission/mandate.

It seems to me that this delegation text does not improve the
situation of the Community Team compared to the current non-delegated
team. I do not think it serves the actual needs of the project, nor
that it will help address the problems that have caused burnout and
high turnover rates.


* All of the activities of the CT seem subordinated to the interest
and willingness of other parties to work with them and listen to their
advice. No provision is made for when this is not the case.

* In particular, Debian events are not required to do anything. This
can result in big events going ahead without any kind of support for
on-site conduct issues, as it was almost the case for DebConf19 (when
the CT noticed the omission just before DC started).

* It mandates the team to coordinate responses, but my experience
shows that other teams -such as DAM or the DPL itself- do not always
collaborate when discussions get heated and coordination is most needed.

How is the team going to make that coordination happen? How is it
going to prevent burning out people when they are left alone to face
the angry mob?

* There are mentions of community-wide harassment, which is of
critical importance, but I see a lack of focus in the small problems
that slowly but persistently erode the environment and result in
Debian constantly losing volunteers. Is this not a need of the project?

* At a first glance the people chosen do not seem to reflect the
diversity of our project, which is of tremendous importance when
dealing with cultural conflicts. The DPL has stressed repeatedly the
need to find "the right people for the job", but I am still curious
about the criteria.

The less-than-transparent way personnel changes have been handled
lately, combined with this apparent lack of diversity in the team that
has been finally blessed by the DPL is not a great look, IMHO.



In conclusion, I do not think this delegation is going to be effective
in helping the CT become a sustainable and useful vehicle to better
our community.

It seems to lack the experience of the tremendous difficulties the CT
has experienced in the past, which is not surprising as most of the
members have only been very recently appointed and the experiences of
past members and project leaders has been systematically erased.

If anything, I see it as a limit to what the CT could have ever
achieved; in a community that still struggles with finding compassion
and kindness, while entitlement and privilege are still the norm, and
figures of power cuddle with with some of the most reactionary voices
in our community, this seems a step in the wrong direction.



Much e-ink has been used to gather wide consensus on many technical
details, whereas discussions around community building and policing
are sorely lacking openness and transparency.

There were many mentions of finding what the project needs to shape
delegations, but I fail to see what are the needs identified that
resulted in this proposal.

Executing this delegation at the very end of a DPL term, during a
pandemic where very few people seem to have any energy left for these
discussions, and while a few dodgy things remain unexplained to the
community is "most emphatically /NOT/ a way to build trust within the
project¹".


Tina.



[¹] To quote a Delegate who compared another proposal with sneaky
power grabs and emotional blackmail.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE2qbv8cYn6hwmsaaSqiMPxF+MJ7EFAl6VVJMACgkQqiMPxF+M
J7HI0w/8Cl05LK2TnO5SBpK2uoIrwRTR/q6GyYJBV7nl5yjbsfYyczekgQ/rVYKq
jS1Bz6Koi2yX5WFUV40gtvJ2x8uh/uySDCEjikfRGQLwwDrSC5Sjp3pai/jY0xj4
lSb0FIicHjS7CVAZ3D1B3Aegk9OWKLC567YVsEC6l8A5IzvqgfjeP/Dm1mg08BND
guGTdlpHzhXLg/KtPFLx5c4kFfNsn2SHfDO8DzZjA2xBe333d5wpnIG84XEfAmvB
IUVzlt+NLGtKTGPeIP2iKfyJnli2olExaQJFbPbGeloEu5kVQJM6qKYsAdpLMwLb
9Np+i9SL0ogLe1Dja1OC+cesZy0zpHT33dpzg2sHTKpzKEXf8YiX3+kBIMt5ATyT
po45aKzQvR7F1Gbg1LFWyc2A5qDoN3q1Ogz8w4hgkVPW8vl52pvMCI4OedeY+/YF
2YXcOcLZxRJC51N6++meaU10oZ0x7FJNf8Hn+Voi1bs7BbAEz4Hr5cci0PePBXmP
1DoJ0GdMySPNJFQcbOffvareoiqqeceQhTgXhtH1sQyouXX43VsOEK8mAfz9+moD
BPR02rHIRXXU84SpDwLEqzNAoVHTmu07jzIFDc2R6602Zh4pRbhcF3KcNhyRG64f
RUbcBpuCbxONJtK8rA3FOwoIXfAgo48N9tGAs74c9mNejndryCo=
=pPXn
-----END PGP SIGNATURE-----


Reply to: