Thanks Karl for the quick answer.
Even though a scientific feedback process is hard, it seems that the
current management could be easily improved. I truly believe that a key
element to have your user base engaged and therefore make your product
better is to communicate with your users and make sure they know they
have been heard. Most of them will then understand your prioritization
decisions and keep up with it even though they may not get what they
want.
I am not sure I am well equipped to manage such a consortium and even if
I was willing to do it (I may be foolish enough to attempt it ;-) I
don't have the time right now.
I would gladly fund part of the work though. I could try to have my
company sponsor part of it (unlikely until we standardize on subversion
which is unfortunately made more difficult by the absence of true
renames...)
Has this issue been researched enough to give a high level estimate? Do
you have any idea of how much effort is required? How much would it take
to have a developer assigned to it? I promise that these figures won't
be used for any negotiation (so please feel free to respond privately if
you prefer ;-)
Jacques
-----Original Message-----
From: Karl Fogel [mailto:kfogel@red-bean.com]
Sent: Thursday, April 12, 2007 3:08 PM
To: Morel, Jacques
Cc: users@subversion.tigris.org
Subject: Re: Subversion 1.5
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 23:22:25 2007