[bitcoin-dev] Three Month bitcoin-dev Moderation Review

[bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Rusty Russell]

Hi all!

        As planned, this is the three month review[1]: discussion of how
moderation should change is encouraged in this thread.

        First, thanks to everyone for the restraint shown in sending
(and responding to!) inflammatory or sand-in-the-gears mails, and being
tolerant with our mistakes and variances in moderation.

The only changes we made to the plan so far:
1) We've stopped clearing the "needs mod" bit after first posts, and
2) Trivially answerable emails or proposals have been answered in the
   reject message itself.

You can see almost all (there was some lossage) rejects at:
        https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/

So, what should moderation look like from now on?
- Stop moderating altogether?
- Moderate <topic> more/less harshly?
- Use a different method/criteria for moderation?
- Add/remove moderators?
- Other improvements?

Thanks,
Rusty.
[1] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[xor]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev wrote:
> So, what should moderation look like from now on?

The original mail which announced moderation contains this rule:
> - Generally discouraged: [...], +1s, [...]

I assume "+1s" means statements such as "I agree with doing X".

Any sane procedure of deciding something includes asking the involved people 
whether they're for or against it.
If there are dozens of proposals on how to solve a particular technical 
problem, how else do you want to decide it than having a vote?
It's very strange that this is not allowed - especially if we consider that 
the Bitcoin community is in a state of constant dissent currently.
The effect is likely that you push the actual decision-making to IRC, which 
less people have access to (since it's difficult to bear the high traffic), 
and thus form some kind of "inner circle" - which makes decisions seem even 
more as if they're being dictated.

So please consider allowing people to say whether they agree with something 
something or don't.


Other than that, thanks for the good latency of moderation, I guess you're 
doing hard work there :)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

I agree with the prohibition of +1s.  The core competency of those who
provide this list are moderation and technology, not managing a process
through which "involved people [indicate] whether they're for or against
it."

That is certainly an excellent function, but it can be offered by anyone
who wants to run a system for collecting and displaying those indications.
The email list itself is intended to be information rich, and such
"approval voting" is not information-rich enough in my view.

It is a shame that the moderated messages require so many steps to
retrieve.  Is it possible to have the "downloadable version" from
https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ for each month
contain the text of the moderated emails?  They do contain the subjects, so
that helps.

On Wed, Jan 20, 2016 at 6:25 PM, xor--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev
> wrote:
> > So, what should moderation look like from now on?
>
> The original mail which announced moderation contains this rule:
> > - Generally discouraged: [...], +1s, [...]
>
> I assume "+1s" means statements such as "I agree with doing X".
>
> Any sane procedure of deciding something includes asking the involved
> people
> whether they're for or against it.
> If there are dozens of proposals on how to solve a particular technical
> problem, how else do you want to decide it than having a vote?
> It's very strange that this is not allowed - especially if we consider that
> the Bitcoin community is in a state of constant dissent currently.
> The effect is likely that you push the actual decision-making to IRC, which
> less people have access to (since it's difficult to bear the high traffic),
> and thus form some kind of "inner circle" - which makes decisions seem even
> more as if they're being dictated.
>
> So please consider allowing people to say whether they agree with something
> something or don't.
>
>
> Other than that, thanks for the good latency of moderation, I guess you're
> doing hard work there :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 3744 bytes --]

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Rusty Russell]

xor--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev wrote:
>> So, what should moderation look like from now on?
>
> The original mail which announced moderation contains this rule:
>> - Generally discouraged: [...], +1s, [...]
>
> I assume "+1s" means statements such as "I agree with doing X".
>
> Any sane procedure of deciding something includes asking the involved people 
> whether they're for or against it.
> If there are dozens of proposals on how to solve a particular technical 
> problem, how else do you want to decide it than having a vote?

+1s here means simpling say "+1" or "me too" that carries no additional
information.  ie. if you like an idea, that's great, but it's not worth
interruping the entire list for.

If you say "I prefer proposal X over Y because <reasons>" that's
different.  As is "I dislike X because <reasons>" or "I need X because
<reasons>".

Hope that clarifies!
Rusty.

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Rusty Russell]

Dave Scotese via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> It is a shame that the moderated messages require so many steps to
> retrieve.  Is it possible to have the "downloadable version" from
> https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ for each month
> contain the text of the moderated emails?  They do contain the subjects, so
> that helps.

Yes, it's because we simply forward them to the bitcoin-dev-moderation
mailing list, and it strips them out as attachments.

I'd really love a filter which I could run them through (on ozlabs.org)
to fix this.  Volunteers welcome :)

Cheers,
Rusty.

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[xor]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Thursday, January 21, 2016 03:14:47 PM Rusty Russell wrote:
> +1s here means simpling say "+1" or "me too" that carries no additional
> information.  ie. if you like an idea, that's great, but it's not worth
> interruping the entire list for.
> 
> If you say "I prefer proposal X over Y because <reasons>" that's
> different.  As is "I dislike X because <reasons>" or "I need X because
> <reasons>".

So "+1"ing is OK as long as I provide a technical explanation of why I agree?
While I still think that this is too much of a restriction because it prevents 
peer-review, I would say that I could live with it as a last resort if you 
don't plan to abolish this rule altogether.

So in that case, to foster peer review, I would recommend you amend the rules 
to clarify this.
Example: "+1s are not allowed unless you provide an explanation of why you 
agree with something".

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Sat, Jan 23, 2016 at 06:33:56AM +0100, xor--- via bitcoin-dev wrote:
> So "+1"ing is OK as long as I provide a technical explanation of why I agree?
> While I still think that this is too much of a restriction because it prevents 
> peer-review, I would say that I could live with it as a last resort if you 
> don't plan to abolish this rule altogether.
> 
> So in that case, to foster peer review, I would recommend you amend the rules 
> to clarify this.
> Example: "+1s are not allowed unless you provide an explanation of why you 
> agree with something".

I would extend this to say that the technical explanation also should
contribute uniquely to the conversation; a +1 with an explanation
the last +1 gave isn't useful.

-- 
'peter'[:-1]@petertodd.org
000000000000000007e2005be0ce25b3f3de67b2dc35fd810b0ccd77b33eb7be

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Gavin]

> On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> I would extend this to say that the technical explanation also should
> contribute uniquely to the conversation; a +1 with an explanation
> the last +1 gave isn't useful.

Yes, comments should contribute to the discussion, with either technical discussion or additional relevant data. I think a +1 like the following should be encouraged:

"+1: we had eleven customer support tickets in just the last week that would have been prevented if XYZ.

Jane Doe, CTO CoinBitChainBasely.com"

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

+1
The distinction we are making importantly requires that contributors
provide readers with another thing to say in favor of something - another
thing which is different than "X people support this instead of only X-1
people."  Evidence trumps votes.

On Sat, Jan 23, 2016 at 1:38 PM, Gavin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > I would extend this to say that the technical explanation also should
> > contribute uniquely to the conversation; a +1 with an explanation
> > the last +1 gave isn't useful.
>
> Yes, comments should contribute to the discussion, with either technical
> discussion or additional relevant data. I think a +1 like the following
> should be encouraged:
>
> "+1: we had eleven customer support tickets in just the last week that
> would have been prevented if XYZ.
>
> Jane Doe, CTO CoinBitChainBasely.com"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 2487 bytes --]

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[David Vorick]

[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]

I do like that the volume of emails has been reduced substantially. I used
to delete hordes of dev emails because I couldn't keep up. At least now I
feel like I'm able to skim most things that look interesting and I get to
assume that if the subject seems relevant to me the content is worthwhile.

My life has improved because of the changes.
On Jan 23, 2016 8:08 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> +1
> The distinction we are making importantly requires that contributors
> provide readers with another thing to say in favor of something - another
> thing which is different than "X people support this instead of only X-1
> people."  Evidence trumps votes.
>
> On Sat, Jan 23, 2016 at 1:38 PM, Gavin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> > On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > I would extend this to say that the technical explanation also should
>> > contribute uniquely to the conversation; a +1 with an explanation
>> > the last +1 gave isn't useful.
>>
>> Yes, comments should contribute to the discussion, with either technical
>> discussion or additional relevant data. I think a +1 like the following
>> should be encouraged:
>>
>> "+1: we had eleven customer support tickets in just the last week that
>> would have been prevented if XYZ.
>>
>> Jane Doe, CTO CoinBitChainBasely.com"
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3592 bytes --]