[libreoffice-design] Re: [libreoffice-design] Formalized team work structures
Hi Philip (H), Phil (J), all, Phil Howards wrote: > Bernard, All, > > An initial draft of a wiki page prototype for new ideas is here: > > http://wiki.documentfoundation.org/Design/Whiteboards/IdeaWorkflow Thanks for this structured approach for a general template. And thanks to Christoph for the template's structure ;-) > > It's just the DocumentBackground page stripped of its content. I'm in > two minds about whether it is better to comment out everything from > Specification onwards, leaving just Summary and Discussion visible > initially. But that's something to do once we've finished deciding on > the page. I would leave them visible, but add something like "can be specified later" to the other sections. This way people know they can work on these parts if they want to, but it's no problem to leave them empty at the beginning. > > Things I like from the DocumentBackground page: > > . Progresses from idea to implementation > . Discussion section near the top means interested parties can read > the relevant threads and handles the transition of an idea from > discussion list to whiteboard. > . Implementation history near the bottom lets the page tell the story > of where an idea has got to, if it is to be implemented in stages, for > example. > . Open items gives space for leftover items so they don't slip through the > net. > > Perhaps links to mockups (much of the whiteboard use in the initial > stages) would go in Discussion. If Discussion includes all the different alternatives and approaches I would like to move it down below Specification. A 1-liner in Specification like "Task still in discussion" would probably not retract interest from Discussion, but would allow to define the specification finally decided on to become more prominent in the end (when discussion is just a part of it's history). > > Using whiteboard wikis for the process is great, because its > asynchronous nature permits sporadic development in the same way > wikipedia does. Also the specification can be fleshed out as it is > developed in the discussions, ready for implementation. It hink the > concept in my mind is coalescence - from an idea of a change to the > details of its implementation. > > The workflow should be changed and refined to suit the process. If > longer-standing members will consistently mark up a whiteboard as it > progresses, we may be able to leave just the Summary and Discussion > sections on the workflow template, and let people reuse the latest > whiteboard that they like, to avoid having one more thing to keep up > to date, or being too prescriptive. I start to think of the main whiteboad page more and more as a table: with a field showing the status of all the entries. If a entry has matured and finalized by the developers they should be moved to a "implemented specifications" page... Best regards Bernhard -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-design] Formalized team work structures
Hi Phil That's a very useful start! Above this we would have a list of ideas, perhaps in two choices of display order - by date started, and by group (related ideas). This list could be a table that shows the stage completed for each item as well as the originator of the idea. This would then be linked back to the Main whiteboard page for the design team. Cheers Phil Jackson On 6/15/2011 6:42 PM, Phil Howard wrote: Bernard, All, An initial draft of a wiki page prototype for new ideas is here: http://wiki.documentfoundation.org/Design/Whiteboards/IdeaWorkflow It's just the DocumentBackground page stripped of its content. I'm in two minds about whether it is better to comment out everything from Specification onwards, leaving just Summary and Discussion visible initially. But that's something to do once we've finished deciding on the page. Things I like from the DocumentBackground page: . Progresses from idea to implementation . Discussion section near the top means interested parties can read the relevant threads and handles the transition of an idea from discussion list to whiteboard. . Implementation history near the bottom lets the page tell the story of where an idea has got to, if it is to be implemented in stages, for example. . Open items gives space for leftover items so they don't slip through the net. Perhaps links to mockups (much of the whiteboard use in the initial stages) would go in Discussion. Using whiteboard wikis for the process is great, because its asynchronous nature permits sporadic development in the same way wikipedia does. Also the specification can be fleshed out as it is developed in the discussions, ready for implementation. It hink the concept in my mind is coalescence - from an idea of a change to the details of its implementation. The workflow should be changed and refined to suit the process. If longer-standing members will consistently mark up a whiteboard as it progresses, we may be able to leave just the Summary and Discussion sections on the workflow template, and let people reuse the latest whiteboard that they like, to avoid having one more thing to keep up to date, or being too prescriptive. Philip H On Tue, Jun 14, 2011 at 11:27 PM, Bernhard Dippold wrote: Hi Phil, all I'm really sorry, that I don't have the time to contribute to the numbers of highly interesting and active threads here on the list. But I don't even manage to read all the mails I receive on the most important LibO lists. (I read all the mails here, even if I don't reply). This mail (sent already three weeks ago [1]) needs some follow-up, and it is important enough to deserve it's own thread. Phil Jackson schrieb (in the thread "flying the ship ...": Hi Bernhard [...] If possible, I'd like to see a degree of formalisation of how the design team will work together with suggestions of stages for taking an idea and transforming it into a form that we have agreement on for submission to the pool of programmers. I support the idea of a common approach for proposals and idea development leading to a final stage agreed upon by the team and proposed to the developers in a way they can work on them. This is about building relationships between the design team members but also between the design team and programmers so they feel part of the design team. It's like selling ideas to management - well articulated ideas with supporting evidence should make a difference in getting done what the Design Team thinks by consensus is necessary to improve the product. It's all about convincing one single developer that a proposal is important, so he is interested in coding in this area. And with some kind of formalism this might be easier - especially as we are in a period where several important ideas are thrown together on the mailing list, while the next steps (collective work, integration with existing designs, UI / UX areas covered...) are not clear to the participants. Here are some suggestions for stages; 1) Someone comes up with an idea :-) should be the basic... 2) Idea is posted on Design/WhiteBoards and emailed to team members In my eyes the /WhiteBoard wiki page should become a table of links to all the items that have been proposed by people really interested in working on them. We definitely need another area, where people can post their ideas for improvement who can't spend the time or have the expertise to work on these ideas. Such ideas need a team member being attracted by the topic and interested in working on it. If there is nobody interested / able to work in it, it might be reactivated by someone scrolling the whiteboard site... 3) Idea is discussed and debated with ample opportunity to test idea and gather arguments for and against ... and improved by the input of other team members. 4) Goes to vote stage by design members after member proposes that they do this - if passed goes to Stage 5) I don't think that we need a formal voting on ea
Re: [libreoffice-design] Formalized team work structures
Bernard, All, An initial draft of a wiki page prototype for new ideas is here: http://wiki.documentfoundation.org/Design/Whiteboards/IdeaWorkflow It's just the DocumentBackground page stripped of its content. I'm in two minds about whether it is better to comment out everything from Specification onwards, leaving just Summary and Discussion visible initially. But that's something to do once we've finished deciding on the page. Things I like from the DocumentBackground page: . Progresses from idea to implementation . Discussion section near the top means interested parties can read the relevant threads and handles the transition of an idea from discussion list to whiteboard. . Implementation history near the bottom lets the page tell the story of where an idea has got to, if it is to be implemented in stages, for example. . Open items gives space for leftover items so they don't slip through the net. Perhaps links to mockups (much of the whiteboard use in the initial stages) would go in Discussion. Using whiteboard wikis for the process is great, because its asynchronous nature permits sporadic development in the same way wikipedia does. Also the specification can be fleshed out as it is developed in the discussions, ready for implementation. It hink the concept in my mind is coalescence - from an idea of a change to the details of its implementation. The workflow should be changed and refined to suit the process. If longer-standing members will consistently mark up a whiteboard as it progresses, we may be able to leave just the Summary and Discussion sections on the workflow template, and let people reuse the latest whiteboard that they like, to avoid having one more thing to keep up to date, or being too prescriptive. Philip H On Tue, Jun 14, 2011 at 11:27 PM, Bernhard Dippold wrote: > Hi Phil, all > > I'm really sorry, that I don't have the time to contribute to the > numbers of highly interesting and active threads here on the list. > > But I don't even manage to read all the mails I receive on the most > important LibO lists. (I read all the mails here, even if I don't reply). > > This mail (sent already three weeks ago [1]) needs some follow-up, and > it is important enough to deserve it's own thread. > > Phil Jackson schrieb (in the thread "flying the ship ...": >> >> Hi Bernhard >> >> [...] >> >> If possible, I'd like to see a degree of formalisation of how the >> design team will work together with suggestions of stages for taking >> an idea and transforming it into a form that we have agreement on for >> submission to the pool of programmers. > > I support the idea of a common approach for proposals and idea > development leading to a final stage agreed upon by the team and > proposed to the developers in a way they can work on them. >> >> This is about building relationships between the design team members >> but also between the design team and programmers so they feel part >> of the design team. >> >> It's like selling ideas to management - well articulated ideas with >> supporting evidence should make a difference in getting done what the >> Design Team thinks by consensus is necessary to improve the product. > > It's all about convincing one single developer that a proposal is > important, so he is interested in coding in this area. > > And with some kind of formalism this might be easier - especially as we > are in a period where several important ideas are thrown together on the > mailing list, while the next steps (collective work, integration with > existing designs, UI / UX areas covered...) are not clear to the > participants. > >> Here are some suggestions for stages; >> >> 1) Someone comes up with an idea > > :-) should be the basic... > >> 2) Idea is posted on >> Design/WhiteBoards and emailed to team members > > In my eyes the /WhiteBoard wiki page should become a table of links to all > the items that have been proposed by people really interested in working on > them. > > We definitely need another area, where people can post their ideas for > improvement who can't spend the time or have the expertise to work on these > ideas. > > Such ideas need a team member being attracted by the topic and interested in > working on it. If there is nobody interested / able to work in it, it might > be reactivated by someone scrolling the whiteboard site... > >> 3) Idea is discussed >> and debated with ample opportunity to test idea and gather arguments >> for and against > > ... and improved by the input of other team members. > >> 4) Goes to vote stage by design members after member >> proposes that they do this - if passed goes to Stage 5) > > I don't think that we need a formal voting on each and every idea. Small > changes should need much less formalism than larger modifications. > > Consensual discussion on the list will lead to a positive feeling of the > team towards this idea. In such a case formal voting is not necessary. > >> 5) A >> Design/Whiteboards paper for the idea
[libreoffice-design] Formalized team work structures
Hi Phil, all I'm really sorry, that I don't have the time to contribute to the numbers of highly interesting and active threads here on the list. But I don't even manage to read all the mails I receive on the most important LibO lists. (I read all the mails here, even if I don't reply). This mail (sent already three weeks ago [1]) needs some follow-up, and it is important enough to deserve it's own thread. Phil Jackson schrieb (in the thread "flying the ship ...": Hi Bernhard [...] If possible, I'd like to see a degree of formalisation of how the design team will work together with suggestions of stages for taking an idea and transforming it into a form that we have agreement on for submission to the pool of programmers. I support the idea of a common approach for proposals and idea development leading to a final stage agreed upon by the team and proposed to the developers in a way they can work on them. This is about building relationships between the design team members but also between the design team and programmers so they feel part of the design team. It's like selling ideas to management - well articulated ideas with supporting evidence should make a difference in getting done what the Design Team thinks by consensus is necessary to improve the product. It's all about convincing one single developer that a proposal is important, so he is interested in coding in this area. And with some kind of formalism this might be easier - especially as we are in a period where several important ideas are thrown together on the mailing list, while the next steps (collective work, integration with existing designs, UI / UX areas covered...) are not clear to the participants. Here are some suggestions for stages; 1) Someone comes up with an idea :-) should be the basic... 2) Idea is posted on Design/WhiteBoards and emailed to team members In my eyes the /WhiteBoard wiki page should become a table of links to all the items that have been proposed by people really interested in working on them. We definitely need another area, where people can post their ideas for improvement who can't spend the time or have the expertise to work on these ideas. Such ideas need a team member being attracted by the topic and interested in working on it. If there is nobody interested / able to work in it, it might be reactivated by someone scrolling the whiteboard site... 3) Idea is discussed and debated with ample opportunity to test idea and gather arguments for and against ... and improved by the input of other team members. 4) Goes to vote stage by design members after member proposes that they do this - if passed goes to Stage 5) I don't think that we need a formal voting on each and every idea. Small changes should need much less formalism than larger modifications. Consensual discussion on the list will lead to a positive feeling of the team towards this idea. In such a case formal voting is not necessary. 5) A Design/Whiteboards paper for the idea if constructed giving a formalised breakdown of the idea - i.e. Overview, Introduction, Main Body with evidence, conclusions (why idea is a good one) and references/bibliography. Designing a mockup to show my ideas to people dedicated to design and UX is not very hard in comparison to preparing a description of modifications leading to developers interest and understanding. 6) Submitted to programmers pool for their feedback. If possible, developers should be involved much earlier. Knowledge about the necessary amount of work on this topic is important for us too. And they are not only asked for feedback - we should try to attract them to work on this topic. Otherwise the idea will need to become pushed by someone else - without any guarantee that it will be worked on sometimes in the future. > 7) Followup We need to make this reasonably professional without turning it into a Phd. It makes it transparent for all. I imagine a wiki page containing these steps (perhaps as a follow-up an other introductory wiki page with all the information a new team member searches for) and all the necessary information about how to attract developers for such work. Christoph already mentioned some kind of "design Easy-hacks", an idea we definitely need to follow. I know that some of these things are already done, but using a system will make it more likely that progress is seen to be made on some very interesting and beneficial ideas. What does everybody think? I think we should try it - and find out about the areas we can improve and further LibO without all these formalisms... Best regards Bernhard Cheers Phil Jackson [1]: http://go.mail-archive.com/80STRNtdj-ankO94T0iTN0CD_MU= -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent
