[Incubator] proposal to graduate MapBender

[Chris Holmes]

Ok, I'm +0 then.  As long as there's a plan in place, and that the 
inside discussion isn't bad.  I'll try to find some time to work on 
getting jira licenses for OSGeo and putting them on a test box.

Chris

Frank Warmerdam wrote:
> 
>> 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,

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/incubator/attachments/20060703/237236e4/cholmes.vcf