Rockbox mail archiveSubject: Re: idea for formalising committal of new features.
Re: idea for formalising committal of new features.
From: Paul Louden <paulthenerd_at_gmail.com>
Date: Mon, 23 Aug 2010 13:51:49 -0500
On 8/23/2010 1:22 PM, alex wallis wrote:
> But who decides what does and what doesn't belong in rockbox, there is
> no formalised structure decisions just seem to be made on the whim of
> one or two people.
If it's simple, one person. If the decision is likely to be contentious
it's (hopefully) discussed with the some of the rest of the developers,
often on IRC. Having a formal process won't change this unless you mean
to make part of the formal process requiring more decisions (since your
complaint here seems to be that it takes too *few* people for a patch to
get included / rejected) in which case nothing will ever reach enough
consensus to be included - probably not what you're going for.
> I am not saying just commit everything, but it seems to me that the
> only way to get things done is to ask and hope someone Responds. If
> there is a set procedure to at least get the ball rolling on committal
> that would be an improvement.
What would you consider "get the ball rolling"? Even if you have a
dedicated "commit manager" he'll still need to get it discussed or find
someone to take responsibility for it. You're basically asking for
someone to volunteer to take your place and bug people instead of you
about the patches you're interested in - isn't this job best suited for
someone who already is passionate about these patches?
> At the very least, surely it would be an idea to have some formal
> tracker review process for both bugs and patches once a year maybe at
> the devcons, or over the period of a few weeks by some kind of review
> committee, to determine the status of old tasks.
> Perhaps some kind of time limits could be put in place so that the
> tracker as a hole is reviewed anually, and tasks that are older than a
> certain cutoff date or that have had no activity for a certain length
> of time should be closed.
> For example some of the bugs also listed on the tracker are years old,
> have they been fixed? Did they even exist in the first place? have
> they even been looked at recently?
> A formal system of tracker review should also investigate that.
Fine, but removing old tasks is completely different from committing
ones that are done. We've done many flyspray cleanup weeks - you can see
exactly how effective they are (to be fair, they've cleaned up quite a
few tasks). How exactly do you intend to make people actually do this?
Just setting a time doesn't work, as it's been done several times. It's
a review project. Instead, why not volunteer to test old bugs, post to
them that they can't be reproduced, and request closure? Again this
sounds like a "somebody else should be doing a job I could take part
in." Remember this is a volunteer project, so people can't be assigned
to a task in any sort of way that guarantees it will be done.
> True, but surely if there is demand for something that should be
> considered. At the moment it seems to me, the decisions of weather to
> close a task, or accept it are made by individuals just as
It will always be made by individuals just as individuals. In the end
one person will always be the one clicking the button. You cannot do
something like this entirely based on popular vote. Public opinion
doesn't include a knowledge of far too many things. As well this project
doesn't belong to the public, it belongs to the developers and their
opinion of what direction it should be going in won't always match the
majority of users.
> Whereas what I am simply suggesting is some kind of formal group based
> discussion at a set time of features, along with a set root for people
> to actively say I would like to see this in rockbox.
Feature requests (a way to say "I would like to see this in Rockbox")
were removed a long time ago. The popularity of a feature is only a part
of the decision, and it's likely there will always be very popular ideas
that are still considered unsuitable. Creating a location for people to
vote on or promote ideas just makes it seem to people like if an idea
gets enough votes it will go in - this isn't true.
Received on 2010-08-23