[stem-dev] Project Communication

[Daniel Ford <webdaford@xxxxxxxxxxxxxxxx>]

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