MC Call Minutes, Mar 19th

[Daniel Holbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman schrieb:
> On Saturday 22 March 2008 02:20:02 Richard A. Johnson wrote:
>> On Saturday 22 March 2008, Scott Kitterman wrote:
>> [...]
>>
>> | So the MC asked and was told no?  I agree there's no bulletproof
>> | solution, but that doesn't mean that cancelling accounts has no value. 
>> | We don't give up on spam filters because they miss some stuff.
>>
>> Canceling an account in this case proved it wouldn't hold any value since
>> he went ahead and created a new account anyways. At least with spam
>> filters, they stop a great majority, revoking an account only stops a
>> person long enough to create a new one.
> 
> When you say ...one of these days something could be done about LP... I take 
> it you (meaning someone on the MC) asked about this and were told no?

Yes, I talked to Launchpad Developers about it back then and was told
that it's a community problem and that Launchpad data surgery would not
help to solve the problem.

A bug about the ability to flag entries (comments, products, branches,
etc.) as inappropriate was mentioned in the conversation:
https://bugs.launchpad.net/launchpad/+bug/45419


> There is a similar issue going on in the IETF right now too.  A problematic 
> person got banned from a working group mailing list, so he created a new 
> email address and started participating.  There the WG moderated his posts 
> and told him that "We think you are person X, so you are moderated.   If you 
> have something worthwhile to contribute it will get in,"  This of course 
> didn't satisfy the individual (having seen just a couple of his posts in the 
> new identity on the main list, it's clearly the same guy).  We'll see how 
> that plays out.
> 
> As it stands the impact of the individual in question (and I agree this is 
> more about what we do for the future now so I'll keep it general) having 
> ignored the MC's request is nothing.  I'm glad he's finally gotten some 
> focus.  It was suggested to him many times before things got to the point 
> they did and he didn't list.  That's great, but from a what can the community 
> do to protect itself perspective, I don't think much has been accomplished.
>
> There is a fundamental difference between us enforcing certain limitations and 
> convincing someone to following them voluntarily.  I believe that there is 
> value in having limitations even if they can be worked around.  In the 
> previous case, if there had been limitations on his account, when the work 
> around account was discovered and merged, then those limitations would have 
> been in place once again.  As I mentioned in an earlier email, people don't 
> disable spam filters because they don't catch everything and take some work 
> to update.
> 
> I think there are two things that would need to be done in Launchpad to give 
> us some ability to throttle problematic contributors:
> 
> 1.  Per project/distro bug capability - Allow projects/distros to disable 
> posting rights for bugs to certain LP accounts.   The account in question 
> would not be able to file, comment of make any status changes on items within 
> that project/distro.  Projects/distros wanting to take advantage of this 
> feature would have to appoint a team/individual to manage the permissions.
> 
> 2.  Account moderation capability (should also be per project/distro) - Allow 
> accounts to be placed in a moderated status.  Any actions made by that 
> account would be queued, but not committed.  A team/individual can then 
> review the qeueue and accept or reject the actions.
> 
> If we'd have had these two capabilities last year, I think that the situation 
> with the individual in question would have never gotten to the point it did. 
> 
> When he did his first sync flood, we could have moderated him so that damage 
> would have been contained.  At that point the community would have had a 
> lever to encourage more thoughtful behavior.  As it was, all we could do was 
> clean up after and get frustrated (I realize that latter was strictly 
> required, but at least in my case it was unavoidable).
> 
> If it had gotten to the point that he was asked to not contribute, when he 
> did, he could have been blocked for a period and then given a moderated 
> chance of showing he'd improved without the risk that he'd dump a huge volume 
> of disruptive stuff on us.
> 
> I do think tools like I'm describing are useful to protect the community and 
> encourage appropriate contribution even though they can work around them if 
> they choose to.  Generally I think if someone works around a ban by making a 
> new account one of two things will happen:
> 
> 1.  They will repeat their bad behavior and be identified (as happened this 
> last time).
> 
> 2.  They will reform and no one will ever know.
> 
> I consider either of those a win since the real point is to get net positive 
> contribution.

Have a nice day,
 Daniel


- --
My 5 today: #206670 (gnarwl), #204666 (ubuntu-docs), #196846 (git-
core), #206270 (xserver-xorg-video-amd), #136495 (llvm)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH63o2RjrlnQWd1esRAtwyAJ9ZrnZilA5ZmBji9darmuCj5EfXzACfZxBu
+mUSKqxZhLmAWfNHMY/HeQ4=
=6l8f
-----END PGP SIGNATURE-----