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.