Re: [stem-dev] Project Communication

[Yossi Mesika <MESIKA@xxxxxxxxxx>]

I totally agree with every word that Dan
wrote.
I would like to emphasis two ideas.
The first one is the idea of Dan to have more "written" discussion
in the mailing list. I think it will be for the benefit of all of us but
especially to those who find it difficult to join the weekly calls and
those who are in listener modes. I'm sure there are many who are just following
the mailing list without taking part in weekly calls. So routing most of
the discussions to this mailing list will benefit those and will also naturally
have it all documented for future follow up on issues.

The other idea is to have more organized
building / releasing roadmap. It mainly means having fixed dates for integration
/ release build but the more important thing is to have a documentation
of what has changed since last build. We will then be able to publish those
updates as a "What's new" on the web site and announcements and
have an easy way for users and developers to understand what are the new
features and what bugs were fixed.

Well that was my 2 cents.

Regards,
Yossi Mesika




From:      
 Daniel Ford <webdaford@xxxxxxxxxxxxxxxx>
To:      
 STEM developer mailing
list <stem-dev@xxxxxxxxxxx>
Date:      
 04/03/2011 01:06 AM
Subject:    
   [stem-dev] Project
Communication
Sent by:    
   stem-dev-bounces@xxxxxxxxxxx

---

With the recent changes to the STEM committer ranks,
I think we have an 
opportunity as an Eclipse project to communicate more effectively within
our group, and more importantly with the greater Eclipse development 
community.   We now have a more diverse and geographically dispersed
set 
of committers.  This, I think, warrants a re-examination of how we
are 
communicating project issues, design decisions, and other project 
information.

Currently, we have a weekly phone call which I started a few years ago
when the project was much smaller.  That was useful then and it still
helps to "socialize" the team members with each other, but as
a channel 
for effective communication, it has a very narrow bandwidth.  For
instance, last Wednesday's call was all of 32 minutes long, it had nine
participants and "discussed" nine different topics, that's less
than 
four minutes per a topic.  Unfortunately, the three new committers
on 
the project were not able to attend.  The timing of the call at 1pm
EDT 
is also a problem, it is good for North America, but not necessarily 
good for any place else.  I know there are Australian Researchers,
who 
have contacted me about joining the project, for whom that time is 
particularly bad, and, as a result, they are not regular participants on
the call.  Also, listening to the last call, I heard a number of issues
I haven't heard discussed previously in any other context or channel.  
The issue of what to do with the level-3 data was one.  I am the 
original author of that data set and am familiar with the context that
surrounds it, but in the short time span of a quick call, it is 
difficult to understand, discuss and then offer a considered opinion on
the issue.  That's why I requested Jamie to post the issue to stem-dev,
thanks Jamie!  The "branching" issue is also a new one,
at least for 
me.  I'm not sure exactly what the issue is, and I haven't seen any
discussion about it in any other context, so it is hard to offer an 
opinion or expertise.  I know from experience, for instance, that
branching in SVN, our current repository, has a fair degree of 
"cognitive overhead" (i.e., you gotta think about it to get it
right, 
and you have to continue to think about it to keep it right), where as
branching and maintaining branches in Git is particularly easy and 
automatic.  Again, it is hard to discuss the merits of different 
approaches in such a short call, or to enlist the expertise of people 
not able to make the call.

Another, more fundamental, problem, especially for an open source 
project, is that our short discussions leave little record for others to
follow.  There is a summary posted to stem-dev each week, but it 
reflects the brevity of the call and doesn't really form a basis that 
captures the issues and decisions of the project.  This makes it 
particularly difficult for outsiders to understand the project, figure
out how to contribute, and then, eventually, to join it.  I note that
over the past year, there have been a number of people and groups who 
have joined the call, only to disappear shortly thereafter.  Those
are 
just the ones we know about, we have no idea how many talented 
contributors looked at the project, didn't like what they saw and moved
on without comment.

One of the fundamental requirements of the EDP is that the projects be
"open" to anyone as well as being "transparent" in
their activities.  It 
is hard for me to argue that we have been fulfilling those obligations.
 
Yes, the phone call is "open," but it isn't really what I would
call 
accessible, nor does it provide for a free discussion, much of an open
debate, or transparent decision making.  I also note that there was
a 
closed "committer only" call last Monday, March 28'th.  In
my opinion, 
that call violated the EDP.  I did not schedule the call, but upon
personal reflection, I think it was a mistake for me to sanction it by
participating in it.  In the future, I will not participate in such
closed calls.

Eclipse is aware that open, transparent and efficient communications in
open source projects is often a challenge, so they have provided the 
projects with newsgroups and developer mailing lists.  There is some
traffic on the STEM newsgroup, but little on stem-dev.

To improve our communications, and fulfill our obligations as an Eclipse
project, I suggest we immediately move all of our discussions about 
development issues, project priorities and other related topics to 
stem-dev.  The phone call can still be useful, but instead of having
an 
agenda with a variety of four minute "bullet points," I suggest
we 
select a single topic and use that time to discuss it in depth, and then
have someone post a summary of the discussion on stem-dev for others to
follow.  Of course, we should use stem-dev to decide on each week's
discussion topic.  These changes should help our new committers to
integrate faster into the STEM team, help us attract new talent to the
project, and help us to engage more openly and more transparently with
the Eclipse community as a whole.

Comments?

Dan Ford
STEM Project Lead
_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev