[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] bugtracking and open source labor

From: Brandon J. Van Every
Subject: [Chicken-users] bugtracking and open source labor
Date: Sun, 10 Dec 2006 16:52:21 -0800
User-agent: Thunderbird (Windows/20061025)

felix winkelmann wrote:
On 12/9/06, Dan Muresan <address@hidden> wrote:
More remarks:

* even with debug: #f, spiffy still logs 404's to stdout (or stderror
-- not sure).

* sxml->html breaks naming conventions and makes it hard to use the
macro define-http-resource.

All your remarks are correct. I will try to address them once I find
the time. I dunno yet how to address some of the points without
breaking backwards compatibility, though.

Anyway, I'm slowly approaching the point where I can't handle
all feature requests and bug reports and I feel we need a bugtracking


I agree on the need for a bugtracking system. On the other hand, we also need labor. Filing bugs doesn't matter much if nobody fixes them. If there's only 1..2 people who actually do work, then this mailing list is an informal bug tracking system.

Similarly, automated testing would catch a lot of bugs. But then, will people fix them? Will people even go to the trouble to implement the automated testing system?

These are the conundrums of open source growth. I don't know what the answer is here; I haven't passed through this project stage before. A lot of open source projects have $$$$$ attached to them somehow. Like a university researcher for instance. Lacking $$$$$, there's a corresponding lack of resources for taking on certain things. Unless people volunteer.

And as we know, volunteering can be personal suicide, with all the support burdens one can conceivably take on. I know I'm not interested in signing up for more burdens than I've already taken on, i.e. just maintaining and gradually improving the CMake build. I didn't get any game development done at all last year. Because of the rabbit holes I've spent time chasing down, my resume is not buzzword-compliant, and nobody is hiring me. Basically in the past 3 years I've found clever ways to become smarter and more interesting as a programmer, at the expense of stagnating my career. In the coming year I'm going to work on consulting skills, to get around the HR drones who only understand buzzwords.

It seems to me that burdens we ask of people, and even of ourselves, need to be SUSTAINABLE burdens. I'm not sure what that would entail. Sustainability is measurable: how many hours a week do stupid problems suck out of one's life? Is there a way to make gradual progress on some of these problems, and to distribute the labor of such problems, so that it isn't some huge perceptual onus?

A vision that comes to mind, is a dynamic "bug notifier." Bugs would be classified according to type and difficulty. Volunteers would sign up for a bug feed that they're interested in dealing with. Classifying bugs, in and of itself, would be a job and have a feed associated with it. When the feed sends an e-mail about a bug, it would list all the people on the feed, as well as the number and difficulty of bugs that people have taken on in the past. Everyone would have a score, so to speak. The score would be used to raise awareness that there are, in fact, other people working on bugfixing problems. And, that some people do entirely too much work, like Felix. A little guilt / peer pressure for everyone to at least make some small contribution.

What do people think of this, in theory? In practice, I don't have the skills to implement such a distributed app. But it seems to me that bugfixing needs some kind of high tech labor model, or open source goes nowhere. I've seen many, many projects where it's basically just 1 guy doing most of the work. Such projects are not sustainable, i.e. if Felix gets hit by a truck, Chicken dies. Also, it's a limit upon project growth.

Brandon Van Every

reply via email to

[Prev in Thread] Current Thread [Next in Thread]