new RPM version and Feature process

[John Poelstra]

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