Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stem-dev] stem-dev Digest, Vol 25, Issue 3

I am all in favor of us making better use of stem-dev, and agree on it's value - especially for people who are in other timezones.
Developers should absolutely use stem-dev for this purpose.

Regarding the call, it is already our practice that anyone can submit agenda items to the call for discussion. These can certainly include
issues that require in depth discussion.

I do not want to restrict the call to only one topic per call. As Dan points out, giving everyone an opportunity to speak does not take much time.
The phone call is also intended as a vehicle for new users (not only developers) to meet the team, describe their interests, and ask questions, and make requests.

Yossi,
I like very much your suggestion on the building / releasing roadmap.
Right now the formal dates exist only in the metadata on the Eclipse Website.
The leads are supposed to maintain this. To make it possible for others to have input
on upcoming builds and releases I'm thinking we might want to add a wiki page where
any developer can document changes (new features, new requirements) since the last release.
We can also put the target dates for future integration builds and release builds on this page (and of course make sure
the meta-data stays up to date. The wiki page could contain important information that we can't list right now in the
metadata such as new plugins that must be added. What do you think?

Best Regards,
Jamie

IBM Almaden Research Center, 650 Harry Rd.
San Jose, CA 95120-6099
email: kaufman@xxxxxxxxxxxxxxx
phone: (408) 927-2477  (tie 457-2477)




From: stem-dev-request@xxxxxxxxxxx
To: stem-dev@xxxxxxxxxxx
Date: 04/03/2011 08:59 AM
Subject: stem-dev Digest, Vol 25, Issue 3
Sent by: stem-dev-bounces@xxxxxxxxxxx





Send stem-dev mailing list submissions to
                stem-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
               
https://dev.eclipse.org/mailman/listinfo/stem-dev
or, via email, send a message with subject or body 'help' to
                stem-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
                stem-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of stem-dev digest..."


Today's Topics:

  1. Project Communication (Daniel Ford)
  2. Re: Project Communication (Yossi Mesika)


----------------------------------------------------------------------

Message: 1
Date: Sat, 02 Apr 2011 18:06:19 -0400
From: Daniel Ford <webdaford@xxxxxxxxxxxxxxxx>
To: STEM developer mailing list <stem-dev@xxxxxxxxxxx>
Subject: [stem-dev] Project Communication
Message-ID: <4D979DDB.40903@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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


------------------------------

Message: 2
Date: Sun, 3 Apr 2011 16:11:33 +0300
From: Yossi Mesika <MESIKA@xxxxxxxxxx>
To: STEM developer mailing list <stem-dev@xxxxxxxxxxx>
Subject: Re: [stem-dev] Project Communication
Message-ID:
                <OFA8BCE8E3.C76E42BA-ONC2257867.00469628-C2257867.004875C8@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://dev.eclipse.org/mailman/private/stem-dev/attachments/20110403/51e84656/attachment.htm>

------------------------------

_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev


End of stem-dev Digest, Vol 25, Issue 3
***************************************



Back to the top