Re: Mediation

[Andrew John Hughes]

On Fri, 2004-12-31 at 00:07, Robert Schuster wrote:
> 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.
> 

Yes, no doubt this is true in your case, but I was speaking more
generally.

> >  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.
> 
No, which is what I was trying to imply by the last sentence (though not
very clearly).  What it does do is introduce a new group of people who
want to generally contribute to a project, but aren't allowed to code on
it due to being tainted.  This is a different group from those who want
to specifically contribute in ways unrelated to coding, and one which I
believe doesn't exist without the notion of an untainted requirement. 
Those people may have chosen code without this requirement, but don't
have the option in this situation.  Hope that makes sense.

> >     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.
> 

Sounds great -- I would be interested to see any end products produced.
As to volunteering, I have no doubt that this is how it would work in a
FOSS situation.  You just have to be aware that this is more difficult
to administer than formally assigning a task in a local team situation.

> >  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.
> 
A wiki sounds fantastic; we've been using one for the project we're
developing at my University, and it does have a low usage barrier, as
you say.  It's great to be able to just go on there, and jot things
down, without the thought needed for HTML or such like.  In fact, I like
the experience so much, this is now the primary method of doing things
on my own website.  It would certainly be very appropriate for a
changing set of GNU Classpath material, which currently requires CVS
committals to change.

> cu
> Robert
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath

Good luck,
-- 
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

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