classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mediation


From: Andrew John Hughes
Subject: Re: Mediation
Date: Tue, 28 Dec 2004 02:34:18 +0000

On Tue, 2004-12-28 at 00:29, Robert Schuster wrote:
> Hi fellow GNU Classpath developers, 
> 
> for some time now I am participating in this project fixing bugs and
> adding functionality mainly to the java.beans package. Despite my good
> knowledge of the Java language, participation in development
> communities and especially the GNU community, is virgin soil to me. As
> a result I sensed a steep learning curve when I started helping
> Classpath. In the last weeks I found myself asking a lot of questions
> on topics which I think are common knowledge for a fair amount of you.
> 
> The problematic cases range from specific tool usage over project
> plans to general policies. I know there is a lot of tool documentation
> on the net and a hacking guide for Classpath which is enough for the
> fundamental stuff like CVS usage or coding guidelines but what I think
> is still left untouched are questions like:
> 
>       * What is the outcome of discussions? 
>       * Whom can I ask directly for specific questions? 
>       * What is the general direction of the project? (or: What is
>         considered old stuff which should be avoided in favour to
>         newer decisions?) 
> 
> 
> Ideas on making this situation better with the intent to make the
> project participation more enjoyful circled in my head and found their
> way on a sheet of paper. It was clear to me that the realization of
> this would need a dedicated effort which cannot be burdened onto
> someone's shoulders without intrinsic motivation.
> 
> After all I am a computer science student who got recently interested
> in software engineering and was seeking a topic for his semester
> thesis. I approached the SE group at my department in order to do an
> academic work around my initial ideas and got positive reponse.
> 
> Now I`d like to ask you if you welcome my effort to enhance our
> project and use the experiences gained from that for academic work.
> 
> The following paragraphs describe the planned enhancements (Criticism
> and comments are welcome):
> 
> My basic assumption is that the development process of an unstructured
> Free software project should be enhanced by non-invasive methods: Any
> means that make the developer's participation work less comfortable
> should be avoided. Academic projects with similar goals as mine have
> largely relied on producing tools which did not get adopted. In
> contrast to that my approach is based around a role that I call
> 'mediator'.
> 
> In short the mediator's goal in a F/OSS project is to take care that
> no idea is lost. To be more specific these are some of the things the
> mediator should do:
> 
>       * Collect information about project member's interests (e.g.
>         package responsibility). 
>       * Remind of certain events: release, urgent documentation
>         updates, long-term goals. 
>       * Keep an eye on the project documentation and guides. 
>       * Be an active guide for newcomers. 
>       * Dig up or re-introduce ideas which otherwise would get lost in
>         mailing-list conversations. 
>       * Write down the results of decisions and ToDo items. 
> 
> 
> It should be noted that I consider that some of these tasks require a
> lot of sensitiveness. A bad formulated ToDo list entry or project
> decision can lead to unfriendly and heated debate. Furthermore the
> mediator does not have any higher privileges: Changes to every
> recorded statement can be made by each project member and the mediator
> does not make decision, but rather collects them.
> 
> The usual work of the mediator will consist of an in-depth study of
> the mailing-list (archive) but also other communication channels like
> Classpath's blog area and IRC. Apart from that he stays in touch with
> the other members and updates the respective documents. The initial
> effort will be on collecting the existing and upcoming data and
> finding a suitable way to organize it.
> 
> The duration of my thesis is limited to 3 months. At the end of this
> time we can look at the results of my work and poll whether to
> continue it or not.
> 
> I hope this introduction gave you enough information to get a picture
> of what I want to do. As stated above criticism and comments are
> welcome.
> 
> Privacy: I respect everyone's privacy but its likely that I will take
> quotes for my thesis from the mailing-lists (which is already publicly
> archived) and perhaps from IRC conversations. In the latter case I
> will address the involved persons and anonymize their statements if
> they want me to do that.
> 
> 
> cu
> Robert
> 
> 
> 
> 
> ______________________________________________________________________
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath

Hi Robert,
        I like this idea of a mediator/librarian role.  Having a physical human
contact for new developers would certainly decrease the learning curve,
and help integrate the newcomer into the project.  Also, as you say,
there are a lot of things which occur on the mailing lists and in IRC
that are not formally noted, with developers instead relying on a kind
of secret wisdom.
        As to actually implementing this idea within a FOSS project, I suppose
it hits the same problems as documentation and such tend to encounter;
namely, that the interest in these activities is less than for the art
of coding.  We have an advantage in GNU Classpath in that developers can
only contribute code if they are untainted, so helpful tainted
developers can add documentation, tests etc.  But, the proportion of
such tasks to code is still pretty low.
        This, I feel, is one of the differences with a FOSS project.  In an
academic or business situation, the team is allocated on a fairly
permanent basis, with members having specific roles.  FOSS is much more
ad-hoc.  People come and go, and there are generally no formal assigned
roles.  AFAIK, the only formal role is GNU Classpath is Mark's position
as lead developer, the guy who handles the administration and acts as
the main point of contact for the project.  Internally, its very much
anyone who wants to do something does it.
        Again, GNU Classpath is fairly non-standard in that:
        a) code developers have to be untainted
        b) its a GNU project with FSF-assigned copyright, so there is a formal
record of all code developers.
This applies more to code than anything else.  My assumption is that
anyone could take on the mediator/librarian role if they don't
contribute code.  This is definitely true for a), with b) it depends on
the quality of the contribution as regards its copyright-ability (at
least, that's British copyright law).
        Whether these issues are good or bad, I'll leave for your thesis.  I
think there is definitely an advantage, in having no formal boundary for
entry into the team.  As you mention, there are informal boundaries in
'getting into the groove', adopting the methodology being used and
finding out how things work.  Could this new role solve this without
removing the openness of the project?
        You also have to deal with the issue that people tend to be more likely
to disappear on such a project.  Someone may take on that job, commit a
bit of work, and then leave.  This happens in academic and business
teams too, of course, but there is more distance between the
participants in a FOSS project.  There is much more reliance on the Net
for contact (being the sole medium mostly).
        At a wider scope, I think you have a more general insight into how
formal methodologies (the idea of the mediator being just one) can be
applied to a FOSS project.  I'd be interested to see your findings on
this.

(BTW, GNU Classpath definitely has the advantage in terms of usable code
output -- most academic projects I've been involved with tend to end up
at the other end of the scale, with too many formalisms and little
output).
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

"We've all been part of the biggest beta test the world has ever known --
Windows"
-- Victor Wheatman, Gartner

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]