From: "Michał Górny" <mgorny@gentoo.org>
To: <gentoo-project@lists.gentoo.org>
Subject: [gentoo-project] ComRel / disciplinary action reform proposal
Date: Sun, 15 Jan 2017 20:23:45 +0100 [thread overview]
Message-ID: <20170115195209.70d3a748.mgorny@gentoo.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 9720 bytes --]
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?
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
next reply other threads:[~2017-01-15 19:23 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-15 19:23 Michał Górny [this message]
2017-01-15 19:38 ` [gentoo-project] ComRel / disciplinary action reform proposal Raymond Jennings
2017-01-15 20:06 ` Rich Freeman
2017-01-15 20:02 ` Rich Freeman
2017-01-15 20:13 ` Kent Fredric
2017-01-15 23:05 ` M. J. Everitt
2017-01-16 17:54 ` Alec Warner
2017-01-15 21:59 ` Dale
2017-01-16 5:00 ` Dean Stephens
2017-01-15 22:55 ` M. J. Everitt
2017-01-16 0:25 ` Jorge Manuel B. S. Vicetto
2017-01-16 0:44 ` Raymond Jennings
2017-01-16 0:55 ` Rich Freeman
2017-01-16 11:16 ` Jeroen Roovers
2017-01-16 19:35 ` Jorge Manuel B. S. Vicetto
2017-01-17 17:38 ` Michał Górny
2017-01-16 4:56 ` Dean Stephens
2017-01-16 13:22 ` Paweł Hajdan, Jr.
2017-01-16 13:40 ` Kristian Fiskerstrand
2017-01-17 4:30 ` Dean Stephens
2017-01-17 4:29 ` Dean Stephens
2017-01-17 17:41 ` Michał Górny
2017-01-20 5:02 ` Dean Stephens
2017-01-16 20:57 ` William L. Thomson Jr.
2017-01-17 17:49 ` Michał Górny
2017-01-17 18:54 ` William L. Thomson Jr.
2017-01-17 19:03 ` Rich Freeman
2017-01-17 19:40 ` William L. Thomson Jr.
2017-01-17 20:20 ` Rich Freeman
2017-01-18 5:33 ` Raymond Jennings
2017-01-18 17:07 ` William L. Thomson Jr.
2017-01-17 14:38 ` Daniel Campbell
2017-01-17 15:26 ` Rich Freeman
2017-01-17 18:05 ` Michał Górny
2017-01-17 18:13 ` Kristian Fiskerstrand
2017-01-18 17:31 ` William L. Thomson Jr.
2017-01-18 18:25 ` Michał Górny
2017-01-18 18:31 ` William L. Thomson Jr.
2017-01-18 19:05 ` Rich Freeman
2017-01-18 19:13 ` William L. Thomson Jr.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170115195209.70d3a748.mgorny@gentoo.org \
--to=mgorny@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox