RFC: Feature process improvements

[Adam Williamson]

On Thu, 2012-11-29 at 05:38 -0500, Marcela Maslanova wrote:

> > Lacks clarification on what's considered an feature.
> > 
> > Arguably it should be mandatory for feature owners to provide or work
> > with the documentation and or marketing communities documenting and
> > publishing what benefits changes their feature brings to
> > users/community/the distribution in whole etc.
> > 
> > it's just absurd having us ( QA ) adjusting release criteria while we
> > are trying to follow it so feature that might affect the current
> > release
> > criteria and or critical components will need to be approved by QA
> > before alpha so we can but not be limited to making the necessary
> > changes to the release criteria in due time and make sure proper
> > testing
> > takes place and each approved feature arguably should have associated
> > test day with it ( if relevant ).
> > 
> > Will it still be optional to participate in the feature process?
> > 
> > JBG
> 
> The discussion about features on f-d could help QA to focus on important
> changes, don't you think? Or would you prefer something else what
> could help QA?
> I'd rather see feature process for wide system changes mandatory. People
> are complaining about features, which went terribly wrong. I don't see
> any other way than control their progress better and help feature owners
> with stuff around (broken dependencies etc.).
> Also in the past some features weren't announced at all and than later
> added because they didn't work well. For example upgrade of Java (I'm not
> picking on Java, just remember this one, but there were surely more).

I'm not sure you two are necessarily disagreeing with each other.
Johann's mail implies a distinction between two types of feature, which
is a common theme of this discussion, and to an extent encoded in your
draft, Marcela:

"so feature that might affect the current release criteria and or
critical components will need to be approved by QA before alpha"

I think ultimately Johann's mail boils down to a suggestion for how to
categorize features - by whether they stand a realistic chance of having
an impact on release readiness - and a suggestion that features which
fall into this category should require QA signoff.

Speaking personally - not for the QA team, we do not have an agreed
position on this proposal - I'm always reluctant with the concept of QA
'approval' of a feature, I don't think it's appropriate for QA to have a
veto on the approval or rejection of a feature in toto. But I agree with
Johann that QA can provide important input about whether a feature will
be sensitive from a release readiness point of view, and what needs to
be done for such features to try and ensure they don't cause release
delays: viable contingency plans, test planning, code completion points,
etc etc.

I'm not sure I want us to have a no-matter-what line-item-veto on
features, but I do think we should be able to set a very high bar for a
feature which looks like it could be seriously disruptive to release
quality and which does not appear to have a viable contingency plan, or
a realistic development schedule, or something like that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net