[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Enhancement requests

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 4 Feb 2015 14:46:07 +0000

Can we manage enhancement requests better?

Users often ask when they can have a certain feature. For example, I was asked recently (for a customer at work) when diff and patch will support full Subversion tree changes such as copy and rename. That's an issue that I personally think is important and has been mentioned in the tracker for a long time (ahem, 2003). Over the years we've added bits of support in the area (such as git diff format) but it still has no road map, and there isn't a single issue describing it, and there is not even a vague design plan written down for it as far as I can find.

The users generally want to know whether the feature is on our roadmap, approximately when we will develop it, and where it is on our priority list -- that is, what other developments are higher priority.

Our usual response is that we don't have a priority list, we only put a few key goals on our roadmap, and it will happen when somebody makes it happen. We say we're volunteer-led so there's no way to force anything to be done. But is it good for us to have no priorities about most proposals and not to make any further decisions about the proposed enhancement, just leaving it to possibly happen one day? I think it would be good for us if we were a bit more active in managing things.

I think one element needed here is some way in which the user can see what *is* planned. Communication often helps things go well in life generally. For an enhancement that is not planned, we might suppose there would be not much to see, but there should still be something saying: "yes this enhancement is
one that we agree we want, and is waiting for developer resources to do
it". Or "this proposal has been assessed as not currently of much interest to the community as a whole, but of course this decision can be reviewed if anyone wishes".

Would it help if we maintain some sort of priority indicator in the issue tracker or on the web?

Should we be going through the issues in the tracker and "triaging" them,
deciding how sensible/important/feasible they are and rejecting the weak ones, much more actively than we currently do? I would be willing to do more of that.

Should we spend a bit more time jointly exploring some of the main ideas that we're all largely aware of (things we broadly agree we want but haven't dug into), a sort of sketching out of high level design goals, that would not be binding but could then be recorded as projects that are a bit more ready to work on that just an initial idea?

Should we spend a bit more effort on our web pages, particularly the "what's in development and what's next" pages? I think that would be useful in encouraging potential helpers to get interested and to contact us.

What do others think?

- Julian
Received on 2015-02-04 15:47:02 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.