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) |