-----BEGIN PGP SIGNED MESSAGE-----
As many of you reading -core are aware, I have written up a proposal for
how to effectively handle devrel's procedures in the future to avoid a
problem like this.
While I would have loved to be at the meeting tomorrow to discuss the
proposal in greater detail, I will be working during that time frame.
So I'm posting the proposal here to generate some discussion here before
the meeting so hopefully everyone can understand why I wrote this.
This proposal is meant to clarify the devrel procedures for
investigation and action taking, and making the decision making process
more transparent. This does not take the power away from devrel, mearly
splits it within devrel to ensure that an outcry over how the situation
was handled happens again.
The current proposal can be found here:
I contacted ciaranm with this proposal to get his input, and in a very
professional manner he pointed out some shortcomings that I feel are
relevant and need to be addressed (I will forward these emails if anyone
wishes if/when I receive his permission to do so).
Some of these points should be implicit, but I guess it makes sense to
make them more explicit:
- Members of the Investigative Subproject should not be members of the
Judicial Subproject to ensure the capcities remain seperated, and
intimate knowledge gained by the investigative subproject (and therefore
private) cannot be used to make decision (which requires the evidence be
public). Making this distinction explicit reduces the chance for human
error in that regard.
- Management should not be allowed to sit on either board, since doing
so inhibits their ability to properly appeal a decision. Althoug the
terms in the proposal are not this stringent, I do feel this is a
- Evidence used must have the supporting context available. This
might include the relevant forum posts, IRC logs, etc. This is to
ensure that a misunderstanding does not result in unreasonable action
against a developer.
If the people here agree with any of these points, I will add them to
the proposal as necessary, but I felt it worthy of discussing them first
before changing the wording on the proposal.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
email@example.com mailing list