As I was contemplating redacting a feature proposal, some thoughts regarding the current process came to mind.
I am not much a huge contributor and half-drunk now but here are my 2 cents... The adopted feature-oriented release plan is a recognition of the real value created by any software: helping user realize her tasks with useful mechanisms. In a way we have adopted a part of the Agile manifesto by focusing on user value instead of other metrics (LOC, fixed bugzilla entries..whatever).It is good for both users and the developers. The former receive more features in a predictable manner, while the latter have clear functional goals to reach. Code improvement/addition is only justified by the feature, can encompass several modules and have functional tests to pass. Life is good... But could be better. Indeed, I couldn't find any resource on what a Gnome Feature is.Is it a feature that integrates many modules ? Is is a radical addition to one of the application modules ? Should application maintainer advocate each new features of its baby as a Gnome feature. Some light might be shed there. Moreover, the current features proposal lack IMHO some data that would streamline the process of feature review. First and foremost, none of the current proposals include a clear Definition Of Done (DoD): its contract in the form of functional test cases (scenarios). The release team could use those to validate a feature inclusion or its delay to the next release. Also, features proposal are currently scheduled for the next release only. This forbid proposals that envision a longer development time. Proposals could be posted without any planned release time, then prioritized/evaluated by both the release team and the author to conclude in a target release. Finally, current process do not enforce intermediate feature releases. They are often dropped in the end of cycle, without much testing and validation. Some intermediate milestones could be requested from the features implementors. In summary, we could adopt some agile (mostly Scrum here) practices for the global planning. Features being use cases and their list a kinda backlog. The release team would have a clearer view on its priorities and the state of each feature, IMHO.What do you guys think ? Voila, Happy Coding,Alexandre _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
