[Incubator] proposal to graduate MapBender

[Chris Holmes]

Cameron Shorter wrote:
> I popped into the IRC and had a quick chat with Seven.
> 
> Using a bug tracker slows developers down.  The bug tracker only becomes 
> valuable when the project becomes too hard to manage in people's heads.
> 
> Complexity is created as a consequence of:
> * code size
> * rate of development
> * number of developers
> * geographically distributed developers

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.

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

 > 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

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.

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.

Of course, if your project is just getting started, then the bug 
database will contain very few bugs, and there's not much you can do 
about that. But if the status page emphasizes the project's youth, and 
if people looking at the bug database can see that most filings have 
taken place recently, they can extrapolate from that that the project 
still has a healthy rate of filings, and they will not be unduly alarmed 
by the low absolute number of bugs recorded.'

Chris


> 
> While this has some great advantages, in the long term, I think this 
> will make it harder for Mapbender to attract new developers.  External 
> developers may find they feel excluded from conversations that happen 
> verbally.
> 
> So I see the lack of a standard bug tracker as an indication of a 
> developer community which may have difficulty attracting outside members.
> 
> That said, I think that Mapbender is ready to complete incubation.
> +1 for me.
> 
> 
> Arnulf Christl wrote:
>> On Mon, July 3, 2006 03:30, Frank Warmerdam wrote:
>>
>>> Cameron Shorter wrote:
>>>
>>>> Could someone please expand on how Mapbender proposes to handle 
>>>> bugs.  I
>>>> had similar concerns to Frank regarding bug tracking and would like to
>>>> see how this is to be addressed.
>>>>
>>>> My vote: +0
>>>> Will be +1 after seeing a solid plan to set up a bug tracker.
>>>
>>> Cameron,
>>>
>>> I don't believe there is any plan in place.  But Uli has called a
>>> Mapbender
>>> PSC/dev meeting for Monday to address the issue.  Perhaps after this he
>>> can report on the plan(s) if any.
>>>
>>> Uli writes:
>>> > dear list,
>>> >
>>> > we invite all members of the dev-list to the following discussion:
>>> > Topic: How to manage bugs for Mapbender
>>> > Monday, July 3, 11:00 (Berlin)
>>> >
>>> http://www.timeanddate.com/worldclock/fixedtime.html?day=3&month=7&year=2006&hour=11&min=0&sec=0&p1=37 
>>>
>>> > irc.freenode.net#mapbender
>>>
>>> I'll try and attend the meeting if I can rouse myself at the appointed
>>> hour.  But from my point of view, I'm happy they are considering the
>>> issue.
>>>
>>> Best regards,
>>
>>
>> Hi,
>> to make a long story short - we tried to get bug tracking operative
>> several times, but it never worked. Some traces can still be found on
>> SourceForge and a more recent faint try is in the CN Project Tracker. But
>> it was never put to any good use - neither by the users nor by the
>> developers, they all simply ignore it. We have it on our long term agenda
>> and will address it once it becomes useful - currently it simply is not.
>>
>> 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.
>>
>> I don't know why, but there has always been a lack of fundamental errors
>> in the software. Practically all issues brought up in the mailing lists
>> can be idnetified and resolved as a problem outside the Mapbender
>> codebase. Its not that the software is so great and perfect but rather
>> that it only glues together other highly standardized pieces of code. I
>> can see that I can't really explain. Maybe our chat will shed some more
>> light on the issue. And yes, I am the first to support a formalized 
>> way to
>> handle bugs. Maybe the neeed will arise as we see more project
>> interaction.
>>
>> Regards, Arnulf.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
>> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>>
>>
> 
> 

-- 
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/88264f0f/cholmes.vcf