Request for MOTU Council to consider Marco Rodrigues (Kmos) not potentially suitable for MOTU

[Marco Rodrigues]

Daniel Holbach wrote:
> Hello everybody,
> 
> as Michael Bienia did in his post, I'd like to add a disclaimer, that
> this does not represent the MC's position, but only my own thoughts.
> 
> 
> On So, 2007-12-02 at 02:32 -0500, Scott Kitterman wrote: 
>> This has been a difficult mail to try and write.  I've struggled with it for a 
>> long time and not come up with a completely satisfactory way to deal with 
>> this issue.  
> 
> Thanks a lot for bringing this up before the MOTU Council.
> 
> 
>> Additionally, I think that frustration with him and the lack of anyone doing 
>> anything about it is the major source of the declining friendliness of 
>> #ubuntu-motu and the MOTU ML in recent months.
> 
> I personally do not agree with this point. Indeed the situation should
> have been brought up in a different forum and dealt with before, but I
> don't think that Marco is the sole reason for unfriendly behaviour in
> the MOTU team. Everybody is responsible for their own bit of
> unfriendliness. I feel this should be part of a separate discussion.
> 
> 
>> It appears to me that nothing of any significance has changed about the work 
>> that he is doing.  It is overall of negative value and disruptive to Ubuntu 
>> development.  The only change is that he's been less active lately.  When 
>> he's active, things appear to me to be of the same low quality that we've 
>> been seeing for months.  
> 
> I don't agree with this point either. Marco's work still needs review
> and counselling but it has improved a lot over the last weeks.
> 

I want to learn more =)

> 
>> This is an unprecendented request, but this is an unprecendently 
>> distruptive 'contributor'.  Before making this request, I consulted with Jono 
>> as the Ubuntu community leader to determine the appropriate forum to resolve 
>> our concerns.  He told me that MOTU Council should evaluate this for Ubuntu 
>> (I had thought it would be the Community Council, but he said MOTU Council 
>> had the authority to decide this).
> 
> Indeed. While most of the MOTU Council's work up until now was related
> to MOTU membership, it's clearly part of the MOTU Council's charter.
> 
> 
>> 1.  That the MOTU Council make a statement that it does not believe that in 
>> the near term he has the potential to be a MOTU.
> 
>>From reviewing his work for a longer time now I get the impression that
> Marco has the tendency to do too many things at once. I personally feel
> that until this changes, Marco can't become a MOTU - he needs to be more
> careful.
> 
> 
>> 2.  That the MOTU Council make a provision for reconsideration at a later date 
>> so that this is not a permanent decision (my though is if he can privately 
>> convince two MC members he's deserving of another chance then they can bring 
>> it to the community and we can decide).
> 
> About your point I like that you're not trying to exclude Marco, but
> leave the door to the MOTU team open.
> 
> I have a different idea though. What do you think about this:
> 
>       * To address your point of disruptive behaviour, Marco will be
>         asked to agree to run all of his work by volunteers. I'm willing
>         to be one of them. 
>       * The volunteers will report every two weeks about what's going
>         on.
> 

I agree with that.

> That way whatever Marco attempts to work on will not disrupt the work of
> others, but still he can contribute and also we'll actively track
> improvement (or lack thereof and have objective data points) and make a
> decision based on that feedback. Maybe we can call this a 'probation
> period'.
> 

I always subscribe Daniel Holbach to my bug reports, but if Michael Bienia wants
to review my work, I can also subscribe him too or another MOTU Council Member.

> 
>> 3.  That the MC ask for all of his Ubuntu related Launchpad priviledges be 
>> revoked (he is involved in at least one other project that uses LP, so it's 
>> more complicated than just suspending his accoung).
> 
> I don't see any worth in this. Marco will have to respect the MCs
> decision.
> 

Exactly.

> 
>> 4.  That the MC tell him he is invited to read the MOTU mailing list and the 
>> IRC channel so that he can continue to attempt to learn, but that he is not 
>> to give advice/answers or disrupt the activities of developers (asking the 
>> channel generically for an answer wouldn't count, but bothering specific 
>> developers would).  That the MC authorize IRC operators and mailing list 
>> admins to enforce this if he does not restrain himself.
> 
> We'll have to find a balance between not misleading new contributors,
> not trying to set up a "mischief police" and keeping everybody
> productive.
> 
> 
> After commenting on all the points of your proposal, I'd like to add a
> few thoughts of my own. Your initial mail was a good attempt at trying
> to address all the problems around Marco. While this is important, I
> think it's even more important to have the general discussion.
> 
> Which problems did we face programmatically? What can we do to fix them?
> 
> Problems I can identify are: 
>       * confusion of who's responsible for dealing with the problems
>       * lack of integration of Kmos in the team (I'd have expected Kmos
>         to ask for more advice)
>       * much earlier escalation to the MC
>       * <please add points to the list>
> 
> 
> It's important to draw the right conclusions out of this as it's a
> precedent and has a much higher impact than just this situation. I chose
> the solution I proposed above under the assumption that we use a similar
> process the next time much much earlier.
> 
> To me it's more important to learn something out of this incident and
> make proper programmatic changes for the future than trying to cowboy
> somebody out of the team. (I don't specifically refer to Scott's
> proposal with this comment, just as a general thought and advise.)
> 
> Thanks again Scott for your work on your proposal.
> 
> Have a nice day,
>  Daniel

-- 
Marco Rodrigues

http://Marco.Tondela.org