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

Re: new RPM version and Feature process



Matthias Clasen said the following on 07/09/2008 07:54 PM Pacific Time:
On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote:

I'm all ears. What are your specific ideas for a more effective process so it is worth all the "trouble and effort"?

We've spent a lot of time up until now trying to get to a useful process, including the public reviews of the process we have at the start of each release. More participation and concrete suggestions from people like you would be greatly appreciated :)


Here are some comments on my recent experience with the feature process:

I've just 'gotten back' a ton of feature pages with the comment 'please
complete section a, b, c...' - but there is no definition anywhere of
what each section is supposed to contain, so how can I know what
'complete' means ?

Fair enough. I believe in most cases requested information was for sections that were completely blank. Up until now I thought the section headings were self-explanatory--I believe you are the first to raise this point about needing definitions, which we can definitely address. I hope people will read them.

So, I have to fly blind and put something in each section in the hope
that it passes the next time. But it feels like there is a lot of
overlap between the (undefined) topics on the feature template: If I've already filled out the 'detailed description', why am I asked to
provide more details in the 'summary' ? And if I've already listed a ton
of packages that need changes under 'scope', whats supposed to be put in
'dependencies' ? etc...

Good point. I can see where defining the sections would help for these. In terms of requesting more for the summary--that information gets listed on the overal summary page for all features so I thought it would be helpful to readers of the summary page if the summary for that particular features was more descriptive and talked in less technical terms.


In general, I think this whole process might be more pleasant if it felt
less like writing a paper and getting it graded and more like a
collaborative process. E.g. if instead of 'please complete the user
experience section' I got some questions back like: 'I didn't quite
understand how to turn this on, will there be a menu item ?', 'does this
also require changes to package foo ?'.

I agree that doesn't sound like fun and I apologize if that is how the reviews have come across. I confess that in most cases I don't have the full technical background or understanding of the feature (another reason why FESCo reviews them) to know whether information in one section of the form supplements another or appropriate technical issues that should be raised. In most cases I'm just trying to do a high level review to make sure the feature page is complete so that when FESCo reviews them it isn't a waste of their time as it was in the past when key sections of the form were blank and it had be discussed again at the next meeting. The feature policy does state this as a requriement, though I understand better now where you are coming from.

The more positive collaborative process you are suggesting--which parties would that be between?

Thanks for your feedback
John


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