I sympathize with your desire for some kind of scientific process of
requirements gathering, but I don't think the way popular open source
projects work is conducive to that kind of process. True, we used a
formal requirements-gathering process for merge tracking, but that's
because CollabNet funded it!
The developers here tend to set priorities according to:
- What users seem to need done
- What that particular developer needs done
- How hard a particular task looks
- [in some cases] What someone is paying the developer(s) to do
The last point is key: you can get true renames to happen faster by
paying a developer to work on it. You might, understandably, complain
that this would be prohibitively expensive. Exactly! Now you know
why developers are so reluctant to pick it up :-). It's hard.
Another approach, if you're up for it, would be for you (or someone)
to put together an informal consortium of interested parties, to share
the cost of finishing the true renames work. You'd each contribute a
little bit to fund a developer. Naturally, there's some overhead in
writing the contract, organizing the funding, etc -- that's something
you'd have to take on. Or the developer could do the organizing, and
just include that overhead in the bill.
(I've sometimes considered doing that myself, but at the moment am
booked with other stuff and would like to finish the sparse
directories feature. Perhaps in the future I'll try this strategy.)
We mostly ignored the voting information in the issue tracker, because
it only included one dimension (desirability, but not difficulty), and
it suffered from sample bias -- people who register an account and
make comments in the issue tracker are not representative of all
Subversion's users. Often, users behind corporate firewalls are not
aware that there's a public issue tracker; sometimes they're even
*prohibited* from making public comments on open source projects,
believe it or not.
I'm completely in favor of true renames getting finished, of course.
I'm just trying to explain how work gets prioritized here, in the hope
that this will enable you to figure out a way to help.
Best,
-Karl
"Morel, Jacques" <Jacques.Morel@sabre-holdings.com> writes:
> So my question is: how as the subversion development team, have you
> facilitated the gathering of feedback from your user base and made
> sure it wasn?t lost?
>
> As a user, how do I make sure my voice is heard at the right time? How
> do I know when it is time to lobby again for a feature?
>
> Remember, we have daily life too and keeping track of subversion user
> or dev mailing list may be too much to ask (it was for me for the past
> 1+ year).
>
> I could not find anything on the web site about a feedback process.
>
> I believe that without a well defined process to define a release
> scope, it is very hard to get a good idea of your user base needs.
>
>
>
> I suggest you spell out the process and ensure it is simple: some like
> vote on the issue you care about or send an email explicitly to ask
> feedback on content of next release or publish a wiki document and let
> people comment on it?
>
> FYI at some point the voting system of collabnet issue tracking was
> available and I invited several co-workers to vote for that issue. I
> suppose it was turned off because you were not using it. Did you have
> reason to reject its information?
>
>
>
> Again, even though I am passionate about this issue, I am also a
> passionate supporter of subversion. So thanks for producing such a
> great tool and investing your [personal] time into it.
>
> My life as a [open-source and closed-source] developer has been made
> significantly less painful since we started using subversion (since
> 1.0 in some projects).
>
>
>
> Jacques
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 12 22:09:18 2007