Re: Mediation

[Robert Schuster]

Thanks for the replies.

Andrew John Hughes wrote:

> 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.
At the beginning it was my personal wish to do that kind of mediation 
(besides programming). The
idea of the semester thesis evolved later. This means that I have that 
kind of interest on doing a specific kind
of non-programming task.

>  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 seems logical but does not work because IMHO tainted developers do 
not automatically
like to do non-programming stuff.

>         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.
My assumption is that tasks can be chosen voluntarily. People decide on 
which part they do coding
and they may decide to do non-programming stuff as well. The result of 
my research will be a handbook
with guidelines for FOSS project mediation. It should serve people 
having an intrinsic interest
in that topic and a project where they want to practise this.

>  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?
>  
This new role shold be a continuation of the openness that the project 
had before. I like
the idea of a Wiki that Mark suggested because it has a low usage 
barrier and reflects
the kind of openness you mentioned.

cu
Robert