Re: Community transparency

On Fri, Mar 06, 2015 at 07:29:23PM +0000, Tom Crocker wrote:
> I think Ian's comments make a lot of sense.
>
> On distributing conflict resolution/sanctions:
> I basically agree. I wonder if having juries/panels of active mb-users or
> auto-editors when it's thought sanctions need to be taken would work. It's
> also worth acknowledging some of the potential drawbacks of a more
> procedural, distributed approach. We've just got rid of the style council
> in favour of a BDFL that has resulted in much greater throughput of style
> issues, with a consistent arbiter who isn't hampered by the rules. That's
> not to say we shouldn't move as Ian suggests but to help weigh the
> arguments (I'm sure there are others).
>

I do see your point here, and I think reporting is the first step --
once we have a better idea of load we'll have a clearer idea of how we
need to spread the workload. But being myself, I also have to note two
things:
a.) the proposal out of which the style BDFL was eventually made (which
was, at the summit, presented by me) was more of a style council -- but
a smaller one, appointed to the task by the powers that be. This turned
into the style BDFL because it seemed like too much buildup of process
for this task. But...
b.) in practice, that's how it works, it's just invisible. reosarevok,
as any reasonable dictator, isn't making decisions without running them
by other central people in the community. And he wouldn't get far if
they disagree! This just usually isn't the case -- certainly not with
the years of built-up cruft with relatively clear solutions to be dealt
with first.

These two things in combination is why I've said a vague thing like
"admins" being in charge, but not specified exactly who that is (not
least of all since it can change!) nor suggested a more built-up process
like juries. We certainly don't want anything to turn into an
mb-style-esque morass, but I'd really like it if we were more explicit
rather than implicit about who's getting input and making decisions,
even if that boils down to there being a list of who's on these
particular email threads rather than nothing, and all of it publicly
being Rob (or reo, for style).

> On reporting:
> again, I agree. two or three confirmed reports (perhaps more for newbies or
> if they all come along at once) and then like a criminal record they
> disappear from public eventually. Make it clear to the offender at each
> case what the process will be and the consequences of further offences,
> including that their actions will be publicised. Report the actions taken
> in response. Should there be different classes of offence with different
> periods of publicity (and possible sanctions)? e.g. not leaving an edit
> note, pretty minor, engaging in personal attacks or creating multiple
> accounts to vote more serious.
>

The main reason I hadn't included multiple levels is because most of
this stuff is pretty obvious, I guess, and in a system that's got a
prudent amount of impermanence built in, it's not going to cause harm to
have your profile say "didn't leave edit notes $n times" for a few
months. It's still a repeat offense, and I think our editors are smart
enough to discern it's less serious of a thing than your other examples.
So why make it more complex than it needs to be? :)

> We should also make it much easier for people to report problems - to even
> know this is possible. (I'm pretty sure reosarevok wrote this somewhere
> recently. CoC debate?)  They should also be reassured that if it's for
> something minor it won't result in drastic action.
>

Yeah, this is planned. Hence my quip at the end about how I should
probably get to writing it! The exact details aren't completely clear
yet, but we certainly want "report this user (privately, for now)" to be
a more prominent option than the current "maybe email support, if you
can find that email, or pester someone in IRC?". Whether that'll be a
quicker button-press to send an email to [email protected] and
then it gets cataloged and processed manually, or something more
complicated, we'll figure out. And probably evolve as we figure out what
we want :)

> Just my thoughts

> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

_______________________________________________
MusicBrainz-devel mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlT67ZAACgkQq+0avXExp29sVQCfQ4I/RIC2vACSmLKn7BWcESvB
IaQAnR5yVf/vjaPtDOCtKozx/hg5013N
=7eRM
-----END PGP SIGNATURE-----