[Incubator] proposal to graduate MapBender

[Frank Warmerdam]

> Cameron Shorter wrote:
>> Complexity is created as a consequence of:
>> * code size
>> * rate of development
>> * number of developers
>> * geographically distributed developers

Cameron,

Well, I don't think you *need* a complex project to justify a bug
tracker though it does help encourage it.  For instance, Daniel Morissette
uses a bug tracker for stuff like MITAB and AVCE00 even though essentially
he and I are the only developers and for AVCE00 might only have one bug
report a year.  But partly that is because he and I are accustomed to using
bug tracking for projects.  Likewise, I use source control even for short
term, one man development projects since I have become accustomed to it.

Chris Holmes writes:
> Well, I'll also say that complexity is only half of the story.  The ease 
> of use of the bug tracker and it's ability to slot in to good workflows 
> can greatly enhance its uptake.  With GeoTools we never used our 
> sourceforge bug tracker, but when we got JIRA going on codeahaus the 
> tracker was suddenly a big win.  It'd notify you automatically of new 
> issues or updates, it was easy to search issues, had a nice interface, 
> ect.  I'm not saying JIRA is the way for MapBender, though it could 
> help.  We could apply for an osgeo license pretty easily.

Chris,

Interesting point.

>> After chatting with Seven, it seems that the Mapbender team have not 
>> been forced into setting up a bug tracking system because 5 members of 
>> their team can all talk with each other.
> Hrm, this is really, really bad actually.  Having people able to talk to 
> each other can kill an open source project.  It closes off transparency, 
> makes new people feel like outsiders.  And doesn't give an opportunity 
> for newbies to help out, by checking out open bugs.

I am certainly concerned that there can be an "inside" vs. "outside"
divide any time a large part of the developers for something are in
one place.  Similar issues would apply for stuff like ka-map, GeoServer
and uDig I would imagine.  But from what I see, the Mapbender team has
made a real effort to include outside contributors in decisions and
discussions.  I also think that the main alternative to a bug system
to discuss problems has been to discuss them on the mailing list which
is accessable to outsiders.

>  > It gives me the impression that we would impose a technical and
>  > operational barrier to an otherwise perfectly well working informal
>  > way of doing things.
> If 'informal way of doing things' is talking in person, then I think 
> that technical and operational increase should be considered in the name 
> of open-ness.  Even if there aren't many bugs, since most of the bugs 
> are in the things being connected, a task tracker can still be super 
> useful for new features, so people can get a sense of what might come 
> next and when.  Check out our roadmap built on issues that are next: 
> http://jira.codehaus.org/browse/GEOS?report=com.atlassian.jira.plugin.system.project:roadmap-panel 

Mapbender does maintain a wiki page with near, mid and long term development
plans.

> I'm actually -0 on mapbender graduation, as I think a clear plan for a 
> task tracker should be in place.  I'd almost go -1 if I had time to help 
> provide JIRA.

At the meeting this morning, the Mapbender PSC agreed to utilize an
OSGeo supported bug system hosted on OSGeo systems when it is ready.
They have also assigned a "bug czar" to be responsible for ensuring
bugs are being followed up on, assigned to appropriate people and so
forth.  Once established, they will also apply "gentle persuasion" to
encourage use of the bug tracker.

This might be bugzilla, or as Howard suggested this morning Trac
might be a good alternative.

So, my claim would be that the Mapbender PSC has reacted promptly to
put in place a bug tracking plan.

> Also, a quote from Fogel on bug trackers:
> 
> 'The importance of a bug tracking system lies not only in its usefulness 
> to developers, but in what it signifies for project observers. For many 
> people, an accessible bug database is one of the strongest signs that a 
> project should be taken seriously. Furthermore, the higher the number of 
> bugs in the database, the better the project looks. This might seem 
> counterintuitive, but remember that the number of bugs recorded really 
> depends on three things: the absolute number of bugs present in the 
> software, the number of users using the software, and the convenience 
> with which those users can register new bugs. Of these three factors, 
> the latter two are more significant than the first. Any software of 
> sufficient size and complexity has an essentially arbitrary number of 
> bugs waiting to be discovered. The real question is, how well will the 
> project do at recording and prioritizing those bugs? A project with a 
> large and well-maintained bug database (meaning bugs are responded to 
> promptly, duplicate bugs are unified, etc.) therefore makes a better 
> impression than a project with no bug database, or a nearly empty database.

I completely agree with this.  I find sampling a bug database gives
me a sense of the vitality and "responsibleness" of a project.  I would
add we do have "Projects should maintain a discrepancy tracking system."
on our operating principles list, so I think this is one of our "best
practices" we would encourage in any project for which it is suitable.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org