Gentoo Archives: gentoo-project

From: Matthew Thode <prometheanfire@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Comrel Improvements: Expectations of Privacy
Date: Tue, 04 Oct 2016 14:10:52
Message-Id: b5499ea2-fdc9-1218-60ae-73897dd3fc02@gentoo.org
In Reply to: Re: [gentoo-project] Comrel Improvements: Expectations of Privacy by Rich Freeman
1 On 10/04/2016 08:24 AM, Rich Freeman wrote:
2 > On Tue, Oct 4, 2016 at 1:20 AM, NP-Hardass <NP-Hardass@g.o> wrote:
3 >> Per the previous statement in this thread about whether reporting is
4 >> mandatory, is there a way for an individual to ensure that their inquiry
5 >> to ComRel is being forwarded to the body itself rather than handled and
6 >> potentially dismissed without official reporting/escalation? For
7 >> example, if I message a member of ComRel because I'm having some issue,
8 >> do I have any guarantee of it reaching ComRel, itself? Additionally
9 >> (and probably more critically) is there a way for me to check on the
10 >> status (both initial and as a case is progressing)? I would imagine
11 >> without some feedback mechanism, a person experiencing conflict that
12 >> warrants ComRel intervention might feel that their situation is being
13 >> ignored or not handled with an appropriate speed.
14 >
15 > I think that this could probably be best handled with better
16 > documentation/formalization of the engagement model, combined with
17 > tracking.
18 >
19 > My sense is that if you need to engage Comrel you email comrel@ (which
20 > may not be how they're always engaged). The question of how Council
21 > appeals work also came up recently as we haven't had many, and we
22 > would like to document this as well.
23 >
24 > As far as things not falling through the cracks goes, an obvious
25 > solution is bugzilla. As soon as any inquiry comes in, create a bug
26 > to track it. By all means close it the next day if it needs to be
27 > dismissed, but this creates some kind of record of the engagement and
28 > makes it clear that the situation is considered resolved. My sense is
29 > that we're not creating bugs until situations become fairly severe,
30 > which will of course make it easier for things to fall through the
31 > cracks.
32 >
33 > However, as we've seen on numerous other projects, simply creating
34 > bugs doesn't make things actually happen. I could easily see this
35 > turning the Comrel queue into something resembling the amd64 stable
36 > queue. It would let people know where their complaints stand, but a
37 > lot of the minor stuff would probably still end up in limbo. This is
38 > just my personal speculation based on what I'm hearing, Comrel could
39 > probably comment further.
40 >
41 > I'm not sure if having people complaining that Comrel is too
42 > heavy-handed and also having people complain that Comrel isn't doing
43 > enough means that we're in the Goldilocks zone. It really seems like
44 > one of those roles that is both vital and thankless, because people
45 > are going to want them to take their side, and will naturally be
46 > disappointed when they don't. And, when people complain they really
47 > can't publicly defend themselves because they need to maintain
48 > privacy, avoid defamation, etc. Hence I'm trying to frame this
49 > discussion at a high level in terms of what the policies ought to be.
50 > Whether Comrel is following policy is a different matter (which I'm
51 > sure will end up in a thread at some point, but in the end people are
52 > probably going to have to trust that somebody is doing their job
53 > right). The idea of anonymous stats was a good one though.
54 >
55
56 This brings up the subject of auditablility, which I think is a great
57 idea, but needs to be in another thread (this is about privacy).
58
59 --
60 -- Matthew Thode (prometheanfire)

Attachments

File name MIME type
signature.asc application/pgp-signature