[mylar-dev] communication problems

["Mik Kersten" <beatmik@xxxxxxx>]

The problem with some of the tone of communication on our mailing list,
newsgroup and bugs has gone too far.   

Thank you Lubos for sending your feedback (see thread:
http://dev.eclipse.org/mhonarc/lists/mylar-dev/msg01345.html).  I realize
that it was not an easy thing to do but it is important that your message
was visible because I have been receiving numerous emails of this sort, both
this last week and previously.
 
It is critical to me that we all strive to make Mylar as open, transparent
and welcoming as possible.  Doing so has made us engaging to feedback and
contributions, and has promoted and rewarded meritocracy.  But it is clear
that some of the tone on our public forums has made the project less
welcoming than it should be, which is counter-productive to our openness. 

Eugene: I have urged you repeatedly to show more respect to our users and
contributors.  Unfortunately you have continued to be regularly
disrespectful, dismissive, and sometimes outright insulting in your
communication.  Respectful personal communication is key to an open source
project's software development process.  In the case of our project,
friendly communication is especially vital because we are building something
new, and require high bandwidth to users and integrators in order to figure
out how to do it.  To make this explicit, six months ago I created
communications guidelines and required that all committers follow them or
provide feedback to evolve them (see
http://dev.eclipse.org/mhonarc/lists/mylar-dev/msg00991.html).  Since you
have either not understood, not appreciated, or dismissed the importance of
doing so I will follow up in personal communication to elaborate further on
the guidelines and on the communications problems.  I will also check in
with the Technology PMC again to ensure that the guidelines are clear and
fair.  However, if you are in gross violation of those guidelines again I am
going to ask the Technology PMC to suspend your committer status.  

Your contributions have been valuable to the project and I would be more
sorry to see that happen than anyone.  I have always been vocal about how
much I value your contributions and you passion, have repeatedly defended
you and for better or worse have learned how to pick the technical parts out
of your tone.  But no amount of contributions is worth sacrificing the
friendliness of our communication medium.  User input is our sustenance and
anybody significantly compromising it is taking more away from the project
than they are providing.  This experience has taught me that meritocracy is
not just about what a contributor gives in terms of bugs and code, but also
what effect they have on the overall health and communication of the
project.  

Mik

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Mik Kersten
> Sent: Friday, May 25, 2007 2:34 AM
> To: Mylar developer discussions
> Subject: Re: [mylar-dev] dev build for 3.3M7
> 
> Eugene Kuleshov wrote:
> ...
>  >  Also note that average user won't complain about some feature he
>  > is not aware of. No offense but it is purely lack of imagination.
> 
> All: please note that this tone of communication goes completely
> against
> the mantra of our project and is not reflective of how other committers
> think of the user community.  For a long time our communication
> philosophy has been stated as:
> 
> "Our philosophy is that the user is always right, even if it takes time
> to figure out how or why they are right. Our project thrives on the
> feedback of users, whether they are seasoned experts or newbies.
> Feedback defines how the tool should work, how it should be simplified,
> and how it should evolve."
> http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Communica
> tion
> 
> I never cease to be amazed at the quality of the feedback of both
> newcommers and seasoned users to suggest features, new ideas, and
> variations on the existing UI.  One of the most rewarding parts of my
> job as the lead of this project is that I read every comment on every
> bug report, which has given me a tremendous appreciation for the
> imagination and wealth of ideas and contributions that have come from
> our still rapidly growing user community.  And as a project we are
> going
> to continue striving to make it easier and easier for new users to
> provide feedback by continuing to facilitate bug reporting and
> improving
> the usage reporting mechanisms that we added for 2.0M3.
> 
> -------------
> 
> Eugene, in saying "no offense" you probably realize that I find this
> statement extremely offensive to our user community and know that it
> drives me crazy to see this, so *please* read the communication
> guidelines again.  The main problem with this is that it creates a bad
> dynamic that makes other people shy to post for fear of being flamed
> at,
> and what we want is everyone to post their ideas and opinions freely.
> 
> As usual you have some good technical points interspersed with the
> flaming, so I'll answer those.  But I'm done with the flaming and do
> not
> plan to reply further posts from you on this thread.
> 
> >  SDK have feature to use background-based highliting for CVS stuff.
> So,
> > bad excuse you have. :-P
> 
> This is not enabled by default and I am arguing that it is a bad idea
> to
> have something like this enabled by default for views that have
> sufficiently high fidelity decorators and are frequently visible.  Part
> of this argument comes from experience, since I have worked for weeks
> with a Package Explorer that had foreground highlighting.
> 
>  >  It depends. Monotonous views are hard to deal with and hard to
> pickup
>  > tasks from list of >10 if those tasks have orthogonal
> characteristics to
>  > any sorting or grouping mechanisms provided by Task List view. That
> is
>  > why I and few other users found highlighters quite handy to make
> those
>  > tasks more noticeable.
> 
> Yes, highlighters are great at making these orthogonal properties that
> don't participate in sorting and grouping jump out immediately.  But
> they are extremely expensive visually because they drown out the other
> visual annotations that we use to indicate these properties.  For
> example, we can now instantly pick out which bugs are marked major.
> with the icon overlays, or which ones are overdue.  In my usage
> experience that gets drowned out in the presence of highlighter.
> 
> >  Well, it seems like you have short memory. I will refer you to the
> > archive of the mylar-dev list and the newsgroup. Look for complaints
> > about disappeared highlighters.
> 
> The only statement I know of on record about a user other than you
> needing highlighters boiled down to problems with other parts of the
> pre
> 1.0 UI.  The user's statement (Oct 18, 2006 newsgroup post) was:
> 
> "My current use of Highlighters will probably seem more like a
> workaround to you.  I'm basically using them as you describe the use of
> the scheduling in your recent article.  I started doing that before I
> realized that scheduling could work that way.  Unfortunately, I find
> that the scheduling coloring / workweek filter doesn't really work well
> for me due to issues with the workweek filter view and how the coloring
> is applied."
> 
> This and other points they brought up have either now been addressed or
> will be addressed via other improvements.  So I am again left to
> conclude that you are projecting your opinions and needs onto those of
> others.  That's *not* to say that we will never have a reason to add
> highlighters, just that the current state is that we don't have one.
> 
> The Mylar UI will never be optimized for you and me.  It needs to be
> optimized for intermediates (one of Alan Cooper's axioms that I deeply
> believe in).  I have always taken every one of your suggestions to
> heart.  But if you project something that you are convinced of to be
> something that others need you make it harder for me to do so.
> 
> Mik
> 
> --
> Mik Kersten
> President & CTO, http://tasktop.com
> Project Lead, http://eclipse.org/mylar
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev