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

[Emmet Hikory]

On Dec 11, 2007 8:23 PM, Daniel Holbach <daniel.holbach at ubuntu.com> wrote:
> 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

* Lack of a known means to stop activities other than through
voluntary compliance

    Regardless of the sequence of actions taken to resolve the issue
at this time, the lack of a publically known method of blocking
activity other than repeatedly talking to someone means that we only
have means to control those who respect the community, and voluntarily
abide by decisions taken.

* Lack of an abilty to effectively track community members activities

    Currently, there is no easy means by which to track any
individuals activities (I know I'd have liked to be able to track my
own on several occasions).  This makes it equally hard to determine
someone's total activities when they are doing good work as when
providing oversight.  For mailing lists and IRC, there are generally
public logs, which help, but having a page on launchpad showing every
bug touched (commented, status adjusted, etc.) would be a great help
when reviewing someones activities (and would help protect against a
partial presentation of evidence that was good, or was bad).

* Lack of MC stepping forward to make a statement.

    This is actually represented in two ways.  Firstly by the
disruptive activities of the individual discussed for several months
with multiple public complaints (albeit no escalaction to MC), and
secondly by the statements of two MC members specifically indicating
they are not speaking on behalf of MC.

    In the former case, I suggest that if any member of MC (as well as
any other developer) finds a person or issue to be contentious or
disruptive, it should be brought to MC attention.  It never feels good
to send a complaint, and in a largely volunteer community, it's easier
to ignore an issue and hope it goes away.  Given MC members role, a
statement that there may be an issue, and invitations for comment may
be sufficient to address something before opinions are hardened, and
resolve it in a timely manner.  (note that this in no way invalidates
the point above about it not having been raised: although I think MC
should invite comment, it is also the responsibility of developers to
raise issues for dispute resolution).

    In the latter case, I would encourage MC members to attempt to
indicate that internal discussions are ongoing earlier, and attempt to
establish some consensus of statements as quickly as possible.  While
the available documentation for MC appears to indicate a typical
response of 12 days, it would be nice to see something indicating that
deliberations are underway, and further nice to see statements made as
MC members, rather than personal statements.

* Lack of an efficient communication channel to discuss the positive
and negative contributions of community members.

    Currently, there is no real means beyond complaining about someone
(which isn't always fair or nice) to indicate to others that that
person's contributions may be unsuitable, or need extra attention.
Further, there's no good way to encorage people who demonstrate
excellence.  As a result, we all operate blindly, and none of us have
a coherent picture of the contributions of any community member
(whether casual user, Contributor, MOTU, or core-dev, and even less so
for those outside the developer community)

    A mailing list for this gets full too quickly, but it might be
nice to have a system by which MOTUs could pass positive or negative
points about someone as a community member.  For many, this would be a
constantly increasing source of compliments providing a foundation for
a MOTU application.  For those that need more help, it may fluctuate
until they have adjusted to the processes and understand the
community, at which point they would fall into the category above.
For those that are disruptive, it would provide a clear negative
indication of feeling, and such public shaming may be sufficiently
unpleasant to be avoided, and additional care may be taken to reach
one of the previously described categories (or at least get back to
parity, and depart from the project).


    Completely separately from the above, and in this specific case,
I'd like to state that I find that ~ 70% of the issues Marco raises
are valid, although there are often small mistakes that require
investigation prior to application, and in many cases I find it takes
more time to investigate than it would to treat the consideration as a
unfinished bug report and perform the activities myself (which is not
my typical experience with submissions).  Further, I'd like to note
that Marco's activities early in the gutsy cycle tended to be of
higher quality, and prepared with more care: to me it seems that as
time passed, the effort taken to ensure that not only was there a
solution, but that it was the right solution, that it was implemented
correctly, and that it was documented correctly decreased.  In many
cases, Marco can be helpful, but the sum total of activities with the
recent attention to detail does not provide a net benefit.  I would
welcome a return to the quality of contributions seen ~ 6 months past,
which genuinely assisted in the completion of gutsy as it was
released, and hope that the final solution determined by MC will lead
to a net positive gain for Ubuntu.

-- 
Emmet HIKORY