I had to sit down today to write how design activities have been integrated into the Yocto Project development cycle. Once I finished writing, I realised that this might be of interest to the community somehow. So here it is, for posterity ;)
This is the Yocto Project development cycle for the 1.9 release: https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule The 6-month period is broken down into 4 milestones. Each milestone has planning, development, stabilisation and release phases. The following is how design has been integrated into this process: * M1 is the design milestone: we design new features and produce the necessary design specifications. A high-fidelity prototype and detailed design specification documents should exist by the cut-off date of milestone 1. Design documents are attached to the relevant Bugzilla entry. * M2 and M3 are implementation milestones. In the Yocto Project, design remains very involved during the implementation phase. All patches submitted to the Toaster mailing list that touch the web interface must be reviewed by design and feedback provided accordingly. In this sense, we are exactly like developers doing patch review. These reviews are critical to achieving acceptable interface quality, and use the design documents produced in milestone 1 as a reference. Design work in this phase also involves filling any gaps in the design done during milestone 1, and making any changes needed due to unforeseen issues arising during the development work. Patches must be reviewed promptly, and any design changes must be worked out fast so that we don't block development. * M4: this is a kind of design stabilisation milestone. The goal is to leave the interface in a good enough state, fit for release. That often involves making compromises in scope (cut down things we cannot deliver at an acceptable level of quality), while guaranteeing that new features are still useful and usable (maybe in the future we'll be able to make them also beautiful, but for now useful and usable is all we can aim for). Planning for the next release takes place after the M4 cut-off date. I also tend to use this time to run informal usability testing on the new features, so that we have some visibility of what are the main issues and how they could be fixed during the next release cycle. This is by no means ideal: the mantra of usability testing is "do it early, do it often". But given the design resources we have and the amount of work to be done, it is better than nothing. There you have it: this is roughly how design has been done in the Yocto Project over the past couple of years. If you have any questions or comments, just ask. Cheers, Belén -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
