Hi, I'd like to propose that we utilize the Spec format Ubuntu and Linaro use and track architectural changes through them, that way anybody can contribute to a spec and everybody can create one depicting what needs to be done to have to support for X or Y, or when there's need to replace something with something new and so forth.
This also serve as an archive for new comers to the distro wanting to get up to speed with things. https://wiki.linaro.org/Platform/DevPlatform/Specs/DeveloperImage ^ This is an example for a feature what entails some architectural changes and notice how the *impact* is discussed nicely there. Proper benchmarking data to support a spec should be linked from it or inline or findings recited: https://wiki.linaro.org/Platform/DevPlatform/Specs/boot-performance This also results in clear goals and allows someone that was not neccessariy part of the design process to take participation in implementation. IMHO this will end confusion and fuss that we saw so far with architectural decision when they are backed by user stories and community is taking interest in testing before hand what sort of impact an architectural change has. Opinions ? -Sivan On Wed, Mar 9, 2011 at 5:10 PM, <[email protected]> wrote: >> From: Carsten Munk >> Sent: 09 March, 2011 13:52 >> >> It is more important than ever now to discuss how to do proper >> architecture process in the open. Decisions on architecture -is- a >> power position but also one of big responsibility. It determines >> direction of the actual code in the project. And that's why it's one >> of the most important functions to have properly open in the project. >> So at least contributors know how MeeGo is supposed to be put together >> and that it functions properly. >> >> What do you (architects or even want-to-be architects, please do weigh >> in as well) think would be a proper, simple, understandable >> architecture process that you'd be willing to participate in? > > Of course there are lots of ways depending on impact and priority. One > suggestion, for major changes: > > 1. Anyone can make a proposal/request, describing: > 1.1. what is the customer need, technical + non-functional requirements > leading to the change request > 1.2. what are the options to solve the needs, and what are the impacts on > dependencies > 1.3. how does the proposal solve the needs, and why is it preferred over > the other options and current solution > 1.4. how the proposal is going to be verified/tested/measured against the > requirements > > 2. Open discussion in a given time box (at least 2 days), with the > stakeholders hit by the proposal. Clear OK/NOK from each, with eventual > comments/alternative proposals. During this, the proposal can change. > > 3. Responsible architect decides on due date. If needed, escalate and chief > architect approves. > > 4. After implementation, the architect gets the solution verified according > to the criteria (1.4.). > > For how much of help it is, depends on the architects. They can decide > anyway either way, and they are responsible for the decision and also for > its verification. Architects can be either elected or appointed. It should > be clear who they are, per domain/system. > > Regards, > Zoltan > > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
