From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DB3B3139085 for ; Sun, 15 Jan 2017 22:56:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 329A92241B2; Sun, 15 Jan 2017 22:56:03 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AC7922241B1 for ; Sun, 15 Jan 2017 22:56:02 +0000 (UTC) Received: from [192.168.6.77] ([46.208.76.211]) by mrelayeu.kundenserver.de (mreue001 [212.227.15.163]) with ESMTPSA (Nemesis) id 0LpCPV-1cyMab3mWj-00f7hD for ; Sun, 15 Jan 2017 23:56:01 +0100 Subject: Re: [gentoo-project] ComRel / disciplinary action reform proposal To: gentoo-project@lists.gentoo.org References: <20170115195209.70d3a748.mgorny@gentoo.org> From: "M. J. Everitt" Message-ID: <587BFDFE.9000709@iee.org> Date: Sun, 15 Jan 2017 22:55:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20170115195209.70d3a748.mgorny@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GsxOBVocsdIU1g4Bllba9wWFoil6vpSJ" X-Provags-ID: V03:K0:HpLAdOca8p26c5N01yxatzDuHMSDhJv9sLYejM9vVoxbLCCb/Pm 6LAcy0YoE1tjYRq7p+2bg64RbdK3GjerZSMMw4agsz9Lhae8qeiHIsihrC40tDBaMS3UqRL I1AHGSTGtYOMSCIXxEPXPtdRqQ7mdUxdUgEo9TtAdUB81vKSXmHXm2I8Hnfn8ceA3EPkbpj yW1t11bTxUqwFGJ0Yjtyg== X-UI-Out-Filterresults: notjunk:1;V01:K0:568HbSmd51A=:RN4b+lizL20L4VVKNOpaLx Ph6XD/z9cdBjMq0TH6Uda5/+wSyJGoeUmdPtSrhk53jqCSBq1Z1DZGSr4RRQaHw21fktbqsKI S7GUlAkwMTesdPwPF4z30YinFHrYQYGaYTs8Qoxwabd8vOopqaLxaN08W3sAy70iWNZYspZyK qJQnZ2KQfKakM+FsFIbf5WUN6HmNv5iryknJQfEyPr1ugIVzXWQHeU+vmPJ7fxZQ+lSIFbycO prwRJhNZlL7iealtllsJL0GPAQwD5HFUks1AzRx+KyOvw6hJgC0twGEi6Ug+ht7dpIIddeFqk 4pibTYwzeEpO58ODdP1tlIhe/e4RaoekLZcY6qJxFbxLzZatgQqV2mAgmxW8ROYkLmOQ34kEB G/njDCea+yUH2UdwVHopVHkE0F8ywSF9P6rPjKLGde0lto9zaq/dNGfcP/AMQ2UNcqBr4a5S6 j9M2suPYA7LSQqGOnPzRGkDByRc0/NMvfdjUnGy2rEotfJQ/a17Y3AywQEvtXHkQySeA3xfD7 hoeSEzd5zb2tIWRollC32fRTgV1UAggrTNobUijpF5ZcbqGdWMpRoDvxo4b2TE/DSX668CcDy hAPlSKKT08cZBMLAy4uQVE0dAf+P8s9OXXdbICNnWrEBzSYrovLRD4k5zb/RUpAsQjwtHLrrY QE7OJNSmgemVdamZkpJ49H/pek46dvXNYlihzeegGuB0F2OMUrDl74Xacwh9/9ERAIR0= X-Archives-Salt: 3a2192a6-cad7-4078-a1ac-638041d9e0e1 X-Archives-Hash: 0644bea82d4e8275080fa985dbaaed68 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8GsxOBVocsdIU1g4Bllba9wWFoil6vpSJ Content-Type: multipart/mixed; boundary="rhrkBccpIraPhaxjIC5fDdl06DXJ9LNan"; protected-headers="v1" From: "M. J. Everitt" To: gentoo-project@lists.gentoo.org Message-ID: <587BFDFE.9000709@iee.org> Subject: Re: [gentoo-project] ComRel / disciplinary action reform proposal References: <20170115195209.70d3a748.mgorny@gentoo.org> In-Reply-To: <20170115195209.70d3a748.mgorny@gentoo.org> --rhrkBccpIraPhaxjIC5fDdl06DXJ9LNan Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/01/17 19:23, Micha=C5=82 G=C3=B3rny wrote: > Hello, everyone. > > Since the things around ComRel seem to have cooled down a bit, I think > we can now start a serious discussion on how disciplinary action > handling could be improved. While the recent complaints were focused on= > ComRel, I would like to take a more generic approach since ComRel is > not the only body in Gentoo capable of disciplinary action. > > Therefore, I'd like my proposal to concern all cases of disciplinary > action, involving but not limited to: ComRel, QA, Forum moderators, IRC= > moderators, Wiki admins and any other entity capable of enforcing > a disciplinary action against developers and users. > > Note: throughout the mail 'users' include all people involved on > the Gentoo communication channels, developers, users, bystanders > and bots alike. > > > Problems > -------- > 1. Lack of transparency (this seems to be improving but I don't think > we have a proper rules for that), that causes two issues: > > a. Users indirectly involved in disciplinary action are unaware of it > which causes unnecessary confusion. Example: user is unaware that > a person is banned from Bugzilla, and incorrectly assumes that > the developer or user does not wish to reply to him. > > b. Users presume disciplinary bodies attempt to hide their actions > which unnecessary builds tension and accusations. This becomes worse > when the subjects of those actions are the only sides speaking upon > the matter, and spreading false information. > > 2. Unclear appeal procedure (outside ComRel). For example, users that > get banned on IRC don't have a clear suggestion on where to appeal to > a particular decision, or whether there is any appeal possible at all. > > 3. Lack of supervision. Likewise, most of teams capable of some degree > of disciplinary action are not supervised by any other body in Gentoo, > some not even indirectly. > > 4. Lack of cooperation. Most of disciplinary teams in Gentoo operate > in complete isolation. Users affected by disciplinary actions > sometimes simply switch to another channel and continue their bad > behavior under another disciplinary team. > > > In this proposal, I'd like to discuss introducing a few simple rules > that would be binding to all teams capable of enforcing a disciplinary > actions, and that aim to improve the current situation. My proposed > rules are: > > > 1. Secrecy > ---------- > Due to the nature of disciplinary affairs, the teams involved > in performing them are obliged to retain secrecy of the information > gathered. This includes both collected material (logs, messages, etc.) > and names of the individuals providing them. > > All the sensitive information involving disciplinary affairs can be > *securely* passed only to other members of the disciplinary team > involved in the affair and the current Council members, upon legitimate= > request. The obtained information should also be stored securely. > > It is only necessary for a single member of the disciplinary team to > store the information (or to use a single collective store). > The Council members should remove all obtained information after > the appeal/audit. > > It should be noted that an unauthorized disclosure of sensitive > information by any party involved would be a base for a strong > disciplinary action. > > Rationale: > > a. The collected material sometimes contains various bits of private > information whose disclosure is completely unnecessary and would only > unnecessarily violate individual's privacy. Gentoo ought to respect > privacy of users, and do not invade it without necessity. > > b. Publishing names of individuals involved in a disciplinary action > could encourage the subjects to seek revenge. While keeping them secret= > often does not prevent it (or even worse, causes the individuals to > seek revenge on larger group of people), we ought not to encourage > it. > > > 2. Transparency > --------------- > Any disciplinary action should be announced by the team in a manner > specific to the appropriate media where the measure applies. > The announcement should be visible to all users of that media, > and contains: > > - the name of the user to whom the measure applies, > > - the description and length of the measure applied. > > For example, a ban on a mailing list could be announced to the mailing > list in question. A ban on Bugzilla could involve adding appropriate > note to the user's name, so that all other users see that he can't > respond at the time. A ban on IRC could be stored e.g. on wiki page, > or noted on a bug. > > Furthermore, any disciplinary action must be reported to the Council. > The reporting is done through a bug that is opened at the first > disciplinary measure inflicted on a user, and reused at any following > measures. It should contain the information listed above, and have > the Council in CC. No private information should be ever included > in the bug. > > Rationale: > > a. As noted above, the disciplinary measure often affect more users > than the subject of the action. It is therefore most advisable to > notice them of the action (i.e. that they can't expect the particular > user to reply) and their length, while protecting as much privacy as > possible. > > b. It is also beneficial for the subject of the action to have > a publicly visible note of the measure applied, and clear statement of > its length. > > c. Opening bugs for all disciplinary actions helps teams keep track of > them and their durations, note repeated offenders and finally report > all actions to the Council for auditing purposes. > > > 3. Appeal > --------- > All disciplinary decisions (both actions and refusals to perform > action) can be appealed to the Council. In this case, the disciplinary > team is obliged to securely pass all material collected to the Council.= > The Council can either support, modify or dismiss the decision > entirely. There is no further appeal. > > It should be noted that the disciplinary actions must not prevent > the appeal from being filed. > > Rationale: > > a. Having a single body to handle all appeals makes the procedures > simpler to our users and more consistent. This also guarantees that > all measures can be appealed exactly once, and no channels are > privileged. > > b. The Council is currently the highest body elected by Gentoo > developers with the trust of being able to handle appeals from ComRel > decisions. It seems reasonable to extend that to all disciplinary > decisions in Gentoo. > > > 4. Supervision > -------------- > At the same time, Council is assumed to supervise all disciplinary > affairs in Gentoo. As noted in 2., all decisions made are reported to > the Council for auditing. Those reports combined with appeals should > allow the Council to notice any suspicious behavior from particular > disciplinary teams. > > For the necessity of audit, the disciplinary teams should retain all > material supporting their disciplinary audit in a secure manner, > throughout the time of the disciplinary action and at least half a year= > past it. The Council can request all this information to audit > the behavior of a particular team and/or its member. > > Rationale: > > a. Having a proper auditing procedure in place is necessary to improve > the trust our users put in our disciplinary teams. It should discourage= > any members of our disciplinary teams from attempting to abuse their > privileges, and help discover that quickly if it actually happens. > > b. The necessity of storing information supporting disciplinary > decisions is helpful both for the purpose of auditing as well as for > (potentially late) appeals. Keeping old information is necessary to > support stronger decisions made for repeat offenders. > > > 5. Cooperation > -------------- > While it is not strictly necessary for different disciplinary teams to > cooperate, in some cases it could be useful to handle troublemakers > more efficiently across different channels. > > Since all disciplinary actions are published, a team may notice that > another team has enforced a disciplinary action on their user. This > could be used as a suggestion that the user is a potential troublemaker= > but the team must collect the evidence of wrongdoing in their own > channel before enforcing any action. It should be noted that > disciplinary teams are not allowed to exchange private information. > > When multiple teams inflict disciplinary actions on the same user, they= > can request the Council to consider issuing a cross-channel Gentoo > disciplinary action. In this case, the Council requests material from > all involved teams (alike when auditing) and may request a consistent > disciplinary action from all disciplinary teams in Gentoo. > > Rationale: > > a. Under normal circumstances, a bad behavior on one communication > channel should not prevent the user from contributing on another. > However, we should have a more efficient procedure to handle the case > when user is a repeating troublemaker and moves from one channel to > another. > > b. Preventing information exchange serves the purpose of protecting > users' privacy. The access to sensitive information should be > restricted as narrowly as possible. Disciplinary teams should perform > decisions autonomously to prevent corruption of one team resulting > in unnecessary actions from another. > > > Migration > --------- > It would seem unreasonable to request all disciplinary teams to either > report all their past decisions right now, or to lift them immediately.= > However, if this policy is accepted, all teams would be obliged to > follow it for any further decisions. > > It would also be recommended for teams to appropriate update at least > recent decisions or those that are brought up again (e.g. via appeal or= > repeat offense). > > > What do you think? > I think this looks good Michal, and thank you for putting it together. A clear and concise policy makes it a lot easier for people to understand when they have done something wrong (possibly even unknowingly) and the consequences of it. Having such a policy helps all parties involved to know what is expected of them, and what should be expected at all points in the process. I commend the idea of having a more consistent policy across different mediums, and some means for teams to interact and co-ordinate better. It is perfectly reasonable to anticipate that actions on one medium may not necessarily manifest themselves on another, and as such, any action and its impact should be independently assessed. --rhrkBccpIraPhaxjIC5fDdl06DXJ9LNan-- --8GsxOBVocsdIU1g4Bllba9wWFoil6vpSJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJYe/3/AAoJEEwwM0+TwiNx+8UP/0uyUVO7Wl0N7M3Wel6YXD6w j/fuMnClX1fLLj7KVqJ5A3vhOvxKAutA/hkC7AmFBuyPBk1Fr6Nhq3qdKSf/7NpM /P9+8OgWNbiaxEh8u2ekWnztH6RRBpVNtmp739jYe/B5TF6wqKOi4HaZP+BM/aed jV4m16BwoUdsv3swaMnTHpnG/SEHbT6Xh0IpYSeWWuFDnOsB3VzGDrrz6IAoRKiB 8atYsSkzGYplLpnfTCP/KYhvtNfuzCSozHiQ+qJeqwXTLm8Tw9eYOXMUsBstadHl 8ue+qXlP2C6oGcKRzYWTgLGN7US+TsqH9joJAcNF8iuboIGjDUUq070G+DpBDHuW 1ETEn/wmQngTpoT+Nnmjx08C4RVYtiG0fWDwP6jOQOpspEh8PH4m37BnEG0xy6fY vmdbDoc4iMIuX9fSFV0gWg25PW9poGpqnQ1BIc6OKdqjsMNyk7f9koCH93Ilopj3 fZaXnjaTUQLCHM4BWNhCk2POVQi/hZOgdwgY4vB0Tf8YWbX8Wz4kkvz9Vxn/B2zJ 29WYM3uGuIYnmIu9ux1fJ1NgQu50lPSDuu504fPf9Wc87h85QC3J2BDt0TN8yvtY bWMo1H3iP1YshL2zZ6gSiRqW5Vhj4dV4hiUakcbORL/BlQP4Ec/FNVIClcQikQ2n VF5ULFVyg8ngMxGAbCfL =w3qX -----END PGP SIGNATURE----- --8GsxOBVocsdIU1g4Bllba9wWFoil6vpSJ--