Re: [proposal] going Agile
After some thinking, I think this is not easy to answer without more clarification. So I have updated the List I have once started (Now called Points of Interest). Added the going Agile topic, and will clarify the Point. So no one has to read this discussion in order to get the picture. The List contains more points. That are points I think they are interesting to look into, my top points have my name behind them. If anyone wants to add points or clarify points, please feel free to edit / extend with sub pages. I have added my name behind the points I put currently focus on. On 18.02.2018 00:52, Peter kovacs wrote: How long should a reasonable demonstration period be? And what are the success criterias that has to be fulfilled? Am 17. Februar 2018 16:08:10 MEZ schrieb Patricia Shanahan : On 2/17/2018 1:04 AM, Peter kovacs wrote: +1 A practical demo of what the proposals mean in practice will be far more useful than abstract discussion. How about your Idea to check all Arrays and replace them with containers? We would create a master ticket, Create sub tickets for each case. Describing what we have to do. Then distribute the cases and implement it. I try to ask people on recruitment if they are willing to join. Maybe this is a good example to try this approach out. I don't think it is a good example, because it is a long term, open-ended project. It would be better to pick something that can be expected to be completed within a reasonable demonstration period. --- This email has been checked for viruses by AVG. http://www.avg.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
How long should a reasonable demonstration period be? And what are the success criterias that has to be fulfilled? Am 17. Februar 2018 16:08:10 MEZ schrieb Patricia Shanahan : > > >On 2/17/2018 1:04 AM, Peter kovacs wrote: >> >> >> >>> +1 A practical demo of what the proposals mean in practice will be >far >>> more useful than abstract discussion. >>> >> How about your Idea to check all Arrays and replace them with >containers? >> We would create a master ticket, >> Create sub tickets for each case. >> Describing what we have to do. >> Then distribute the cases and implement it. I try to ask people on >recruitment if they are willing to join. >> >> Maybe this is a good example to try this approach out. > >I don't think it is a good example, because it is a long term, >open-ended project. > >It would be better to pick something that can be expected to be >completed within a reasonable demonstration period. > >--- >This email has been checked for viruses by AVG. >http://www.avg.com > > >- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
On 2/17/2018 1:04 AM, Peter kovacs wrote: +1 A practical demo of what the proposals mean in practice will be far more useful than abstract discussion. How about your Idea to check all Arrays and replace them with containers? We would create a master ticket, Create sub tickets for each case. Describing what we have to do. Then distribute the cases and implement it. I try to ask people on recruitment if they are willing to join. Maybe this is a good example to try this approach out. I don't think it is a good example, because it is a long term, open-ended project. It would be better to pick something that can be expected to be completed within a reasonable demonstration period. --- This email has been checked for viruses by AVG. http://www.avg.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
>+1 A practical demo of what the proposals mean in practice will be far >more useful than abstract discussion. > How about your Idea to check all Arrays and replace them with containers? We would create a master ticket, Create sub tickets for each case. Describing what we have to do. Then distribute the cases and implement it. I try to ask people on recruitment if they are willing to join. Maybe this is a good example to try this approach out. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
On 2/13/2018 2:22 PM, Andrea Pescetti wrote: Marcus wrote: @all: What do you think is the first topic we should start with? I think the only reasonable way forward is that Peter chooses one of the many available tasks (digital signatures? Java 9 support? MSVC update? .docx export? you name it) and experiments the workflow limited to it. Even if it is a relatively small project, one can decompose it in many subtasks: none of these is "too simple" for an experiment. This way the rest of the project can continue as always, while we have a proof of concept that can involve volunteers and so on. Once the proof of concept is completed, it can serve as a model for expanding it. Otherwise my feeling is that we will waste too much time discussing the theory and making it perfect, but getting nowhere in practice. +1 A practical demo of what the proposals mean in practice will be far more useful than abstract discussion. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Marcus wrote: @all: What do you think is the first topic we should start with? I think the only reasonable way forward is that Peter chooses one of the many available tasks (digital signatures? Java 9 support? MSVC update? .docx export? you name it) and experiments the workflow limited to it. Even if it is a relatively small project, one can decompose it in many subtasks: none of these is "too simple" for an experiment. This way the rest of the project can continue as always, while we have a proof of concept that can involve volunteers and so on. Once the proof of concept is completed, it can serve as a model for expanding it. Otherwise my feeling is that we will waste too much time discussing the theory and making it perfect, but getting nowhere in practice. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Am 12.02.2018 um 22:15 schrieb Peter Kovacs: On 10.02.2018 13:26, Marcus wrote: Therefore let me summarize: - Use BZ for the development work (e.g, fixing a specific bug). - Work in Jira for the project tasks and technical coordination (e.g., Windows signing). - Use Confluence for project work and as documentation base. - Take the Agile Board functions in Jira if it fits for us. - Also we can see what we need to do to claim "We are working along Kanban rules". ok, lets try this. great However I think we should keep an eye on bandwith needs. That is a good point from Damjan. We are not only a first world thing. We are for everyone and everyone that is willing should have a chance to participate. I have seen also in the discussion that we would like to support other Open Source Projects if we can. We should therefor concider that Jira is only a intermediate solution, to be used until we have a replacement in Bugzilla. Do you agree with my observation? Sure, we can try to participate in other projects. However, I thing we have much to do in our own project. PS: I just wantot repeat a sentence from above: I'm not totally pro or contra your proposal. I just want to express my opinion why not everything you've proposed is fitting for us. My priority is to get a better overview of what needs to be done and that we work better together, so we have a better chance in including new people. I will have an eye on topics what volunteers need. I am looking forward that we break those eggs one after another together. I think I did this one wrong, because I started of what I would like to do and got into a confrontation role, which I did not want to. Tooling and Scrum Framework was not in my center of my goals but It was very important in the discussion. I am a real slow and bad learner. I hope no one takes this personal. I am imaptioned. I apologies to myself and to all others for my uttelress clumsyness. Don't worry too much. Many proposals need to be discussed before coming to a common understanding - and an agreement. Thanks for starting this discussion and to try to improve the project with new ideas. I thank you all for the open discussion and the shown courage to speak up. I believe that these are values that make us work together. Even without Scrum. ;) I hope maybe that others are inspired by this and speak up to. You are all Welcome! One good thing in Scrum is: fail fast (do something and stop when it's not working before wasting more money/time). So, let's try to implement some ideas and watch closely if it's worth the effort. @all: What do you think is the first topic we should start with? Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Hi - Thanks Peter for driving this topic. I don’t think we all agree, but we can (a) try to advance our project organization and (b) acknowledge how we are using the many tools we already use. > On Feb 12, 2018, at 1:15 PM, Peter Kovacs wrote: > > On 10.02.2018 13:26, Marcus wrote: > >> >> Therefore let me summarize: >> >> - Use BZ for the development work (e.g, fixing a specific bug). >> - Work in Jira for the project tasks and technical coordination (e.g., >> Windows signing). >> - Use Confluence for project work and as documentation base. >> - Take the Agile Board functions in Jira if it fits for us. >> - Also we can see what we need to do to claim "We are working along >> Kanban rules". > ok, lets try this. > > However I think we should keep an eye on bandwith needs. That is a good point > from Damjan. We are not only a first world thing. We are for everyone and > everyone that is willing should have a chance to participate. > I have seen also in the discussion that we would like to support other Open > Source Projects if we can. We should therefor concider that Jira is only a > intermediate solution, to be used until we have a replacement in Bugzilla. > Do you agree with my observation? (1) Bug/Issue Trackers available from the ASF. (a) Bugzilla - OpenOffice has a dedicated instance as does SpamAssassin while many projects share a third. (b) JIRA - Atlassian has provided a free license to the ASF. Not all plugins may be available. If one is missing then it will need negotiation. (2) Wikis available from the ASF. (a) MediaWiki. This wiki is supported by the AOO PMC and came over as a legacy from OpenOffice.org. (b) Confluence. (Again Atlassian provided free license) This is hosted by the ASF and the project has two available for organizing various tasks. We used these pretty extensively during migration to organize work. (c) MoinMoin. Also hosted by the ASF - a more old school wiki. Used by the Incubator and others. > >> PS: >> I just wantot repeat a sentence from above: >> >> I'm not totally pro or contra your proposal. I just want to express my >> opinion why not everything you've proposed is fitting for us. > My priority is to get a better overview of what needs to be done and that we > work better together, so we have a better chance in including new people. > I will have an eye on topics what volunteers need. I am looking forward that > we break those eggs one after another together. My suggestion is to use tools we already have. A wiki seems correct to me. I would suggest Confluence, but that is my personal preference. We already have tools deployed. I think we just need to manage a table from time to time. Periodically we can “Scrum” on dev@ over the status. > > I think I did this one wrong, because I started of what I would like to do > and got into a confrontation role, which I did not want to. Tooling and Scrum > Framework was not in my center of my goals but It was very important in the > discussion. > I am a real slow and bad learner. I hope no one takes this personal. I am > imaptioned. I apologies to myself and to all others for my uttelress > clumsyness. Nothing to forgive since you are proceeding with a rational discussion. So we are clear you are looking to have a high/medium level overview of tasks and status towards goals. I think this can be a table in a wiki. > > I thank you all for the open discussion and the shown courage to speak up. I > believe that these are values that make us work together. Even without Scrum. > ;) I hope maybe that others are inspired by this and speak up to. > You are all Welcome! Bitte! (Did I use that correctly?) Regards, Dave > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > signature.asc Description: Message signed with OpenPGP
Re: [proposal] going Agile
On 10.02.2018 13:26, Marcus wrote: Therefore let me summarize: - Use BZ for the development work (e.g, fixing a specific bug). - Work in Jira for the project tasks and technical coordination (e.g., Windows signing). - Use Confluence for project work and as documentation base. - Take the Agile Board functions in Jira if it fits for us. - Also we can see what we need to do to claim "We are working along Kanban rules". ok, lets try this. However I think we should keep an eye on bandwith needs. That is a good point from Damjan. We are not only a first world thing. We are for everyone and everyone that is willing should have a chance to participate. I have seen also in the discussion that we would like to support other Open Source Projects if we can. We should therefor concider that Jira is only a intermediate solution, to be used until we have a replacement in Bugzilla. Do you agree with my observation? PS: I just wantot repeat a sentence from above: I'm not totally pro or contra your proposal. I just want to express my opinion why not everything you've proposed is fitting for us. My priority is to get a better overview of what needs to be done and that we work better together, so we have a better chance in including new people. I will have an eye on topics what volunteers need. I am looking forward that we break those eggs one after another together. I think I did this one wrong, because I started of what I would like to do and got into a confrontation role, which I did not want to. Tooling and Scrum Framework was not in my center of my goals but It was very important in the discussion. I am a real slow and bad learner. I hope no one takes this personal. I am imaptioned. I apologies to myself and to all others for my uttelress clumsyness. I thank you all for the open discussion and the shown courage to speak up. I believe that these are values that make us work together. Even without Scrum. ;) I hope maybe that others are inspired by this and speak up to. You are all Welcome! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
How can I build only core package? I am only aware to build everything, or a certain range of modules, or I can build explicit one module. I do not want to take away the ability to build all in one step. But I think if you are only rebuilding core it saves you a lot of time. And if you can check if there is an effect beyond package boarders, it helps you to avoid the issues that had happened in 4.1.5. Just thinking. I said I am sorry was to hasty in this. Am 10. Februar 2018 14:46:01 MEZ schrieb Patricia Shanahan : > >> On Feb 9, 2018, at 20:05, Peter Kovacs wrote: >> >>> On 09.02.2018 01:19, Patricia Shanahan wrote: >>> On February 8, 2018, at 5:51 AM, Peter Kovacs >wrote: >>> >>> # Devide the Project into different selfcontained parts. so we have >>> smaller chunks to swallow. (Maybe we should consider breaking the >>> compile Process into individual compile steps by package just to >reduce >>> Complexity.) >>> How would this be different from what we have now? The code is >already divided into modules, and the build process builds each to get >the packages. >> I wrote hasty. I do not know for sure since to me the build system is >a big huge black box. >> I want more transperency, better control over the code. >> I think if we hard split the build and only build each package on >their own we will gain a better view on the code. But I could be wrong. >> At least I would like to have the option. > >You already have the option. I am not sure it would help. > >I am a bit worried be “At least”. Any change that breaks build >automation would be impractical for me. I need to issue a single >command, go do none AOO activities, and have my new build ready to test >when I get back. > >- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
> On Feb 9, 2018, at 20:05, Peter Kovacs wrote: > >> On 09.02.2018 01:19, Patricia Shanahan wrote: >> On February 8, 2018, at 5:51 AM, Peter Kovacs wrote: >> >> # Devide the Project into different selfcontained parts. so we have >> smaller chunks to swallow. (Maybe we should consider breaking the >> compile Process into individual compile steps by package just to reduce >> Complexity.) >> How would this be different from what we have now? The code is already >> divided into modules, and the build process builds each to get the packages. > I wrote hasty. I do not know for sure since to me the build system is a big > huge black box. > I want more transperency, better control over the code. > I think if we hard split the build and only build each package on their own > we will gain a better view on the code. But I could be wrong. > At least I would like to have the option. You already have the option. I am not sure it would help. I am a bit worried be “At least”. Any change that breaks build automation would be impractical for me. I need to issue a single command, go do none AOO activities, and have my new build ready to test when I get back. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Am 10.02.2018 um 07:20 schrieb Peter Kovacs: On 09.02.2018 23:08, Marcus wrote: Am 08.02.2018 um 00:32 schrieb Andrea Pescetti: Peter Kovacs wrote: I would like to propose that we apply Agile development methods as much as we can. it depends what you mean with agile. IMHO forget Scrum as we are not the community to get a commitment for this. Why? ahm, you should read what I've posted. Then it's getting clear. ;-) Kanban would be nice. YAY! I take this as a success!! :-D One step forward. Thousands more to go. So where you would establish the board? - Use trello? Confluence? (No ;) ) We use Confluence already, so whay not to continue. Of course we can also create an ODF, commit to SVN and everybody who wants can work on it. We just need to coordinate who and when to commt. Jira has a Backlog and a Kanban board integrated which I am told are very easy to use (Drag & drop I hope...) I know Jira. But I don't think that it would bring us so many advantages. BTW: Drag & Drop is great when you have to move many issues quickly to the next status. Otherwise you can also edit 1-2 fields to change the status. So, I doubt that we need this. Therefore a page in Confluence - used as Kanban board - will do the same trick. But there are other key features that could be nice to have (e.g., simply the graphically based board "One-Page-Overview". At the end it's a bit problematic for us with the attributes of volunteers, their unpredictable working time (time to work on OpenOffice tasks) and the number of volunteers. BTW: Above is IMHO why Scrum is not for us. I mean the workflow etc. Of course we can be transparent, open, etc. anyway. You agree? I don't know if a Product Owner makes sense. Kanban don't know about any roles. ;-) The Product Owner is a single person who tells the team what to do. Then the team can decide how to do it. But I don't want to follow a single person. Why not to decide in the team what to do and not to do? Then we can put it into the list (or call it Kanban board) and take tasks to work on. We can organize the work and, sure, one person can volunteer to act as "Story/Issue writer" and putting tasks into the right order in Jira and its Kanban board. Of course you then can call this person Product Owner. ;-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Am 10.02.2018 um 06:21 schrieb Peter Kovacs: Migration would be done by infra. They wrote up everything need to know: https://wiki.apache.org/general/ApacheBugzillaToJiraMigration I find it cumbersome that all our users should then use Jira to open a bug report. What about to keep Bugzilla for the development work? Damjan has made a very valuable point here (rough quote: BZ issues are linked in SVN, code, webpages, even Confluence.And nobody wants to migrate this stuff - ). But then we can use Jira to organize our project work. If you want you can then also use the Agile Board functions. Again, it is not about the tool it is about the workflow. I would like to have a Kanbanboard, to get transparency what is worked on, who can I approach if I have a volunteer to work together. New Volunteers need someone they can follow. I want to have a Backlog to define what is important to do next, and to fill the detailed steps together what we need to do. Maybe we could together fill out so much detail, that it is easy for everyone to start on the topic. That is the original proposal. I know that Jira is _the_ industry tool to this. Every major professional major Project uses Jira. It would not be so popular if it would not have a certain quality. Yes, but we are not "industry" and also not "professional". Did you know that it is closed source and you need to pay for to be able to use it? ;-) Luckily the ASF got a license free of charge. I know that you complained onec there are so many differnt links to note and tools that we have in our arsenal. I don't complain. I just want to express my opinion why not everything you've proposed is fitting for us. Jira could be reduce the lot. Thats why I think it is convenient. BTW. If we start using Kanban, I will reach out to the one Volunteer who volunteered and loves Kanban if want to have a try with us, we are now following his way (more or less...) Maybe he jumps at it. And that's the point: maybe. We simple don't know if we get more volunteers (that will also stay). Thats the nature of volunteers. They will look if they like what they see and are gone when they are no longer committed. It's great when we get feedback what should be changed, so that they show a higher commitment or simply stay longer. We had another Volunteer who said: tell me what to do I do it. But I do not have the interest to figure it out on my own. We can currently not use these people. With Backlog and Board we can. Sure, these people can help us to go further. With our without a graphical based board. Sure, it's easier with it. Of course we can change some workflows. But I doubt that it would bring us more volunteers when we turn everything inside out. Therefore let me summarize: - Use BZ for the development work (e.g, fixing a specific bug). - Work in Jira for the project tasks and technical coordination (e.g., Windows signing). - Use Confluence for project work and as documentation base. - Take the Agile Board functions in Jira if it fits for us. - Also we can see what we need to do to claim "We are working along Kanban rules". PS: I just wantot repeat a sentence from above: I'm not totally pro or contra your proposal. I just want to express my opinion why not everything you've proposed is fitting for us. Marcus On 09.02.2018 23:05, Marcus wrote: I would prefer to avoid the upheaval of switching to a different issue tracker if at all possible. +1 Jira is just another tool that wouldn't bring us any nearer to closed issues. BTW, start new? Then you would trash all old issues which isn't a good thing. Move them over to Jira? Great, who is the volunteer to do the migration? ;-) But Confluence can bring us some overview. We can structure similar BZ issues to packages and then we can work on them. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
On Sat, Feb 10, 2018 at 12:05 AM, Marcus wrote: > Am 09.02.2018 um 01:19 schrieb Patricia Shanahan: > >> On February 8, 2018, at 5:51 AM, Peter Kovacs wrote: >> >> # Start spreading knowledge in our development team. >>> 1) I would like to propose a Product Backlog / OIL (OpenIssue) List > to priorize Issues we need to work on. The most Valueable item comes > to the top, the least to the bottom. What Value exactly is is up to > discussion. > Theoretically, we have a list of issues in Bugzilla with target 4.2.0. Validating them all and/or setting targets will basically give you what you wish. I think Bugzilla has some concept of an issue weight that would more or less allow to prioritize issues with the current tooling, so this can be done. At least, once we agree on list on a series of "must-haves" for 4.2.0, these could be turned into something similar to your backlog. >>> Maybe we should not discuss tooling now. I think in the end it has to >>> work. Jira is mostly a convenient choice. But we can think of all other >>> sort of combinations. (However we have already a lot of Tools.So I would >>> rather try to reduce those. We can try Bugzilla, but i do not want to >>> start modifying Bugzilla in order to get what we need. >>> >> >> I would prefer to avoid the upheaval of switching to a different issue >> tracker if at all possible. >> > > +1 > > Jira is just another tool that wouldn't bring us any nearer to closed > issues. BTW, start new? Then you would trash all old issues which isn't a > good thing. Move them over to Jira? Great, who is the volunteer to do the > migration? ;-) > > > +1 to that. We have Bugzilla bug numbers in SVN and even in the code, and links to Bugzilla URLs in places too, who is going to find and replace all of those? I also find Bugzilla much faster to work with and lighter on the network (not everyone is in a 1st world country). Damjan
Re: [proposal] going Agile
Openness can be a real problem. I have mainly done security fixes that had to stay on the private lists until released and disclosed. Patricia > On Feb 10, 2018, at 06:20, Peter Kovacs wrote: > > >> On 09.02.2018 23:08, Marcus wrote: >>> Am 08.02.2018 um 00:32 schrieb Andrea Pescetti: >>> Peter Kovacs wrote: I would like to propose that we apply Agile development methods as much as we can. >> it depends what you mean with agile. >> >> IMHO forget Scrum as we are not the community to get a commitment for this. > Why? What does our community do not like about scrum? > We do not like the Values of scrum? > Focus > Openess > Respect > Commitment > Courage > > Or maybe we do not like the pillars? > Transparency, Inspect and adapt? > ;) > > Agreed, I think we can not use SCRUM in the same way Companies do, too. But I > think we can use the Idea of scrum to work together and to simplify our work. > What would you use to make our work simple? > Why do you think Ordering our Bugs in a List and add details to them will not > bring us forward? >> >> Kanban would be nice. > YAY! > I take this as a success!! :-D > One step forward. Thousands more to go. > So where you would establish the board? - Use trello? Confluence? (No > ;) ) > Jira has a Backlog and a Kanban board integrated which I am told are very > easy to use (Drag & drop I hope...) >> >> At the end it's a bit problematic for us with the attributes of volunteers, >> their unpredictable working time (time to work on OpenOffice tasks) and the >> number of volunteers. >> >> However, we should try to keep it simple as Product Backlop, Product Owner, >> Tasks, Sub-Tasks, Jira, Confluence etc. would be much too much complexity >> for us when doing/using all of them. > Maybe I have learned a total different scrum then you did? - Agile does not > mean to use everything like a fixed ruleset. To me SCRUM is a template to > start with It just tells us what prooved to be working well. But How and what > we can use from the framework, is up to us. > > Again. Only Product Backlog, Product Owner, and a Kanban board are on the > table as to be used. And I do only want the Product owner so we have some > steward for the list. I am totaly fine with a Release Manager looking into it. > I have not explained to maximize Value and Output, since I do not believe we > do need to maximize Value and Output, since we are Open Source Volunteering > Community and not OpenSource Commercial Product. Small but important > difference not to forget. (If we get OpenSource Comercial part, we have to > make sure they can spend their energy on maximizing Value. ;) ) > > You agree? > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
On 09.02.2018 23:08, Marcus wrote: Am 08.02.2018 um 00:32 schrieb Andrea Pescetti: Peter Kovacs wrote: I would like to propose that we apply Agile development methods as much as we can. it depends what you mean with agile. IMHO forget Scrum as we are not the community to get a commitment for this. Why? What does our community do not like about scrum? We do not like the Values of scrum? Focus Openess Respect Commitment Courage Or maybe we do not like the pillars? Transparency, Inspect and adapt? ;) Agreed, I think we can not use SCRUM in the same way Companies do, too. But I think we can use the Idea of scrum to work together and to simplify our work. What would you use to make our work simple? Why do you think Ordering our Bugs in a List and add details to them will not bring us forward? Kanban would be nice. YAY! I take this as a success!! :-D One step forward. Thousands more to go. So where you would establish the board? - Use trello? Confluence? (No ;) ) Jira has a Backlog and a Kanban board integrated which I am told are very easy to use (Drag & drop I hope...) At the end it's a bit problematic for us with the attributes of volunteers, their unpredictable working time (time to work on OpenOffice tasks) and the number of volunteers. However, we should try to keep it simple as Product Backlop, Product Owner, Tasks, Sub-Tasks, Jira, Confluence etc. would be much too much complexity for us when doing/using all of them. Maybe I have learned a total different scrum then you did? - Agile does not mean to use everything like a fixed ruleset. To me SCRUM is a template to start with It just tells us what prooved to be working well. But How and what we can use from the framework, is up to us. Again. Only Product Backlog, Product Owner, and a Kanban board are on the table as to be used. And I do only want the Product owner so we have some steward for the list. I am totaly fine with a Release Manager looking into it. I have not explained to maximize Value and Output, since I do not believe we do need to maximize Value and Output, since we are Open Source Volunteering Community and not OpenSource Commercial Product. Small but important difference not to forget. (If we get OpenSource Comercial part, we have to make sure they can spend their energy on maximizing Value. ;) ) You agree? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Migration would be done by infra. They wrote up everything need to know: https://wiki.apache.org/general/ApacheBugzillaToJiraMigration Again, it is not about the tool it is about the workflow. I would like to have a Kanbanboard, to get transparency what is worked on, who can I approach if I have a volunteer to work together. New Volunteers need someone they can follow. I want to have a Backlog to define what is important to do next, and to fill the detailed steps together what we need to do. Maybe we could together fill out so much detail, that it is easy for everyone to start on the topic. That is the original proposal. I know that Jira is _the_ industry tool to this. Every major professional major Project uses Jira. It would not be so popular if it would not have a certain quality. I know that you complained onec there are so many differnt links to note and tools that we have in our arsenal. Jira could be reduce the lot. Thats why I think it is convenient. BTW. If we start using Kanban, I will reach out to the one Volunteer who volunteered and loves Kanban if want to have a try with us, we are now following his way (more or less...) Maybe he jumps at it. We had another Volunteer who said: tell me what to do I do it. But I do not have the interest to figure it out on my own. We can currently not use these people. With Backlog and Board we can. That would mean 2 more developers. Propably. Maybe they quick because it is frustrating to build OpenOffice. *ROFL* On 09.02.2018 23:05, Marcus wrote: I would prefer to avoid the upheaval of switching to a different issue tracker if at all possible. +1 Jira is just another tool that wouldn't bring us any nearer to closed issues. BTW, start new? Then you would trash all old issues which isn't a good thing. Move them over to Jira? Great, who is the volunteer to do the migration? ;-) But Confluence can bring us some overview. We can structure similar BZ issues to packages and then we can work on them.
Re: [proposal] going Agile
Am 08.02.2018 um 00:32 schrieb Andrea Pescetti: Peter Kovacs wrote: I would like to propose that we apply Agile development methods as much as we can. it depends what you mean with agile. IMHO forget Scrum as we are not the community to get a commitment for this. Kanban would be nice. At the end it's a bit problematic for us with the attributes of volunteers, their unpredictable working time (time to work on OpenOffice tasks) and the number of volunteers. However, we should try to keep it simple as Product Backlop, Product Owner, Tasks, Sub-Tasks, Jira, Confluence etc. would be much too much complexity for us when doing/using all of them. My 2 ct. (also with my years of experience as Scrum Product Owner) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
Am 09.02.2018 um 01:19 schrieb Patricia Shanahan: On February 8, 2018, at 5:51 AM, Peter Kovacs wrote: # Start spreading knowledge in our development team. 1) I would like to propose a Product Backlog / OIL (OpenIssue) List to priorize Issues we need to work on. The most Valueable item comes to the top, the least to the bottom. What Value exactly is is up to discussion. Theoretically, we have a list of issues in Bugzilla with target 4.2.0. Validating them all and/or setting targets will basically give you what you wish. I think Bugzilla has some concept of an issue weight that would more or less allow to prioritize issues with the current tooling, so this can be done. At least, once we agree on list on a series of "must-haves" for 4.2.0, these could be turned into something similar to your backlog. Maybe we should not discuss tooling now. I think in the end it has to work. Jira is mostly a convenient choice. But we can think of all other sort of combinations. (However we have already a lot of Tools.So I would rather try to reduce those. We can try Bugzilla, but i do not want to start modifying Bugzilla in order to get what we need. I would prefer to avoid the upheaval of switching to a different issue tracker if at all possible. +1 Jira is just another tool that wouldn't bring us any nearer to closed issues. BTW, start new? Then you would trash all old issues which isn't a good thing. Move them over to Jira? Great, who is the volunteer to do the migration? ;-) But Confluence can bring us some overview. We can structure similar BZ issues to packages and then we can work on them. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
On 09.02.2018 01:19, Patricia Shanahan wrote: On February 8, 2018, at 5:51 AM, Peter Kovacs wrote: # Devide the Project into different selfcontained parts. so we have smaller chunks to swallow. (Maybe we should consider breaking the compile Process into individual compile steps by package just to reduce Complexity.) How would this be different from what we have now? The code is already divided into modules, and the build process builds each to get the packages. I wrote hasty. I do not know for sure since to me the build system is a big huge black box. I want more transperency, better control over the code. I think if we hard split the build and only build each package on their own we will gain a better view on the code. But I could be wrong. At least I would like to have the option. # Start spreading knowledge in our development team. Maybe we should not discuss tooling now. I think in the end it has to work. Jira is mostly a convenient choice. But we can think of all other sort of combinations. (However we have already a lot of Tools.So I would rather try to reduce those. We can try Bugzilla, but i do not want to start modifying Bugzilla in order to get what we need. I would prefer to avoid the upheaval of switching to a different issue tracker if at all possible. The tool is not important. It is just a tool that has to serve a purpose. Important to me is that we change the method we work. In my opinion, YAGNI is just as important for process design as for software design. Thats the principle of lean management. In my opinion we currently work on this method, but keep the PMO structure that the the project was build on from the old days. And thats makeing it all difficult for everyone. If we get to the point of having enough active volunteers that we need to think in terms of forming teams we will know a lot more about their skills, availability etc. and therefore be able to do a better job of organizing those teams. We had 4 or 5 candidates. So far no one stayed. They had a look and went off. You can blame all sorts of things. In reality you have only control over one thing that is you. We do only have the power to change this project. If we want that people stay, we need to change. Not other way round. The question is how we want to change. I like the family trait we have. I would like to use this trait to make people stay. Agile teams in my eyes will open a gate for new people into our community. They start learning some people from the community quickly and as they work they learn more. Becomming more attached. Thats why I am suggesting it. What would you change with the ressources we have to make people stay? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [proposal] going Agile
On February 8, 2018, at 5:51 AM, Peter Kovacs wrote: >Thank you these are good points. >On 08.02.2018 00:32, Andrea Pescetti wrote: >> Peter Kovacs wrote: >>> I would like to propose that we apply Agile development methods as >>> much as we can. >> >> Well, "as much as we can" is the key here. OpenOffice is as agile as >> an elephant. A lot of us use Agile in their daily work activities, and >> maybe they even like it, but it's a totally different vision from the >> Apache/OpenOffice way. >I agree. But I am proposeing to reorganize the project so we do not deal >with the Elefant size we bring from history. >I want ># Core Tasks are done in teams, to releave the commitment on the >individual volunteer ># Devide the Project into different selfcontained parts. so we have >smaller chunks to swallow. (Maybe we should consider breaking the >compile Process into individual compile steps by package just to reduce >Complexity.) How would this be different from what we have now? The code is already divided into modules, and the build process builds each to get the packages. ># Start spreading knowledge in our development team. >> >>> 1) I would like to propose a Product Backlog / OIL (OpenIssue) List >>> to priorize Issues we need to work on. The most Valueable item comes >>> to the top, the least to the bottom. What Value exactly is is up to >>> discussion. >> >> Theoretically, we have a list of issues in Bugzilla with target 4.2.0. >> Validating them all and/or setting targets will basically give you >> what you wish. I think Bugzilla has some concept of an issue weight >> that would more or less allow to prioritize issues with the current >> tooling, so this can be done. At least, once we agree on list on a >> series of "must-haves" for 4.2.0, these could be turned into something >> similar to your backlog. >Maybe we should not discuss tooling now. I think in the end it has to >work. Jira is mostly a convenient choice. But we can think of all other >sort of combinations. (However we have already a lot of Tools.So I would >rather try to reduce those. We can try Bugzilla, but i do not want to >start modifying Bugzilla in order to get what we need. I would prefer to avoid the upheaval of switching to a different issue tracker if at all possible. >> >>> 2) I would further propose that we create a new Role - The Product >>> Owner. >> >> This is the Release Manager and the community. If someone steps us to >> do the "secretarial" work of maintaining issues, you have your >> volunteer; giving him a title is something we normally don't do, but >> this is irrelevant. >yea, we can do so if all are fine by this. >> >>> 3) If we agree on the Backlist I further suggest that we open up a >>> Jira Issue Tracker. >>> We can keep the Bugzilla Bugtracker for tracking the bugs, and create >>> Issues from it. Or we move to Jira completly. >>> Why do I propose the tool change? Because We can track with Jira >>> Issues, have the Backlog and can use a Project wide Kanban board >>> (replacing in part the Sprints from Scrum) to track Which activity >>> has been started. Where we can create Teams. >> >> This won't work. This is tooling that I'm used to using every day, so >> mine is not a resistance to change. Just, it's clear that nobody does >> OpenOffice as his day job, so we can't count on being able to assign >> an issue to someone for example, or on having an issue handled within >> a certain "sprint". At most, we can hope that people will voluntarily >> do a very occasional "scrum" like I do for the localization stuff, >> reporting here when I have some time to work on it and saying where >> I'm stuck and what would be the next step. The rest looks unrealistic. >Let me try to describe the way I think we could make it work. >We form the Core teams. A Core team does consist at least of 1 PMC >(which can take another Role), 2 Programmer and 2 QA Volunteers and is >limited at a maximum of 9 People. Each team is working together and >picks Topics from the Backlog in their TeamBacklog of what they believe >they can handle within the next month (Just to have a limitation on >tasks, but we could also limit as Kanban does it by a fix amount lets >say 3 Items). We do setup a Team List for each team. There they can have >their "meetings" on weekend each memebr posts a Standupmail, which >contains the availability. If he is stuck with issues somewhere. And >maybe if he is on track or not. (Transperency, Inspection and >Adaptaition are the important Buzzwords here) >What does a Core team look into? ># Security Bugs would be a candidate. Not all Teammembers need to be on >the list thought. ># Dependency Migration ># Core Code Changes ># important Bugfixes (i.e. Crashes) >What not? ># new Features ># nice to have ># tooling (except we define something as critical and must have.) In my opinion, YAGNI is just as important for process design as for software design. If we get to the point o
Re: [proposal] going Agile
+1 I am in favor, and like the way duscussions are heading. Willing to contribute in setting up project in Jira if thus goes through On Feb 8, 2018 11:21, "Peter Kovacs" wrote: > Thank you these are good points. > > On 08.02.2018 00:32, Andrea Pescetti wrote: > >> Peter Kovacs wrote: >> >>> I would like to propose that we apply Agile development methods as much >>> as we can. >>> >> >> Well, "as much as we can" is the key here. OpenOffice is as agile as an >> elephant. A lot of us use Agile in their daily work activities, and maybe >> they even like it, but it's a totally different vision from the >> Apache/OpenOffice way. >> > I agree. But I am proposeing to reorganize the project so we do not deal > with the Elefant size we bring from history. > I want > # Core Tasks are done in teams, to releave the commitment on the > individual volunteer > # Devide the Project into different selfcontained parts. so we have > smaller chunks to swallow. (Maybe we should consider breaking the compile > Process into individual compile steps by package just to reduce Complexity.) > # Start spreading knowledge in our development team. > >> >> 1) I would like to propose a Product Backlog / OIL (OpenIssue) List to >>> priorize Issues we need to work on. The most Valueable item comes to the >>> top, the least to the bottom. What Value exactly is is up to discussion. >>> >> >> Theoretically, we have a list of issues in Bugzilla with target 4.2.0. >> Validating them all and/or setting targets will basically give you what you >> wish. I think Bugzilla has some concept of an issue weight that would more >> or less allow to prioritize issues with the current tooling, so this can be >> done. At least, once we agree on list on a series of "must-haves" for >> 4.2.0, these could be turned into something similar to your backlog. >> > Maybe we should not discuss tooling now. I think in the end it has to > work. Jira is mostly a convenient choice. But we can think of all other > sort of combinations. (However we have already a lot of Tools.So I would > rather try to reduce those. We can try Bugzilla, but i do not want to start > modifying Bugzilla in order to get what we need. > >> >> 2) I would further propose that we create a new Role - The Product Owner. >>> >> >> This is the Release Manager and the community. If someone steps us to do >> the "secretarial" work of maintaining issues, you have your volunteer; >> giving him a title is something we normally don't do, but this is >> irrelevant. >> > yea, we can do so if all are fine by this. > >> >> 3) If we agree on the Backlist I further suggest that we open up a Jira >>> Issue Tracker. >>> We can keep the Bugzilla Bugtracker for tracking the bugs, and create >>> Issues from it. Or we move to Jira completly. >>> Why do I propose the tool change? Because We can track with Jira Issues, >>> have the Backlog and can use a Project wide Kanban board (replacing in part >>> the Sprints from Scrum) to track Which activity has been started. Where we >>> can create Teams. >>> >> >> This won't work. This is tooling that I'm used to using every day, so >> mine is not a resistance to change. Just, it's clear that nobody does >> OpenOffice as his day job, so we can't count on being able to assign an >> issue to someone for example, or on having an issue handled within a >> certain "sprint". At most, we can hope that people will voluntarily do a >> very occasional "scrum" like I do for the localization stuff, reporting >> here when I have some time to work on it and saying where I'm stuck and >> what would be the next step. The rest looks unrealistic. >> > Let me try to describe the way I think we could make it work. > > We form the Core teams. A Core team does consist at least of 1 PMC (which > can take another Role), 2 Programmer and 2 QA Volunteers and is limited at > a maximum of 9 People. Each team is working together and picks Topics from > the Backlog in their TeamBacklog of what they believe they can handle > within the next month (Just to have a limitation on tasks, but we could > also limit as Kanban does it by a fix amount lets say 3 Items). We do setup > a Team List for each team. There they can have their "meetings" on weekend > each memebr posts a Standupmail, which contains the availability. If he is > stuck with issues somewhere. And maybe if he is on track or not. > (Transperency, Inspection and Adaptaition are the important Buzzwords here) > > What does a Core team look into? > # Security Bugs would be a candidate. Not all Teammembers need to be on > the list thought. > # Dependency Migration > # Core Code Changes > # important Bugfixes (i.e. Crashes) > > What not? > # new Features > # nice to have > # tooling (except we define something as critical and must have.) > > I would not change language list, or other activities. However if we have > a backlog we could put other stuff there. Like the merchendise Topics. > Those are then a free for all volunteers to care in their time. > >
Re: [proposal] going Agile
Thank you these are good points. On 08.02.2018 00:32, Andrea Pescetti wrote: Peter Kovacs wrote: I would like to propose that we apply Agile development methods as much as we can. Well, "as much as we can" is the key here. OpenOffice is as agile as an elephant. A lot of us use Agile in their daily work activities, and maybe they even like it, but it's a totally different vision from the Apache/OpenOffice way. I agree. But I am proposeing to reorganize the project so we do not deal with the Elefant size we bring from history. I want # Core Tasks are done in teams, to releave the commitment on the individual volunteer # Devide the Project into different selfcontained parts. so we have smaller chunks to swallow. (Maybe we should consider breaking the compile Process into individual compile steps by package just to reduce Complexity.) # Start spreading knowledge in our development team. 1) I would like to propose a Product Backlog / OIL (OpenIssue) List to priorize Issues we need to work on. The most Valueable item comes to the top, the least to the bottom. What Value exactly is is up to discussion. Theoretically, we have a list of issues in Bugzilla with target 4.2.0. Validating them all and/or setting targets will basically give you what you wish. I think Bugzilla has some concept of an issue weight that would more or less allow to prioritize issues with the current tooling, so this can be done. At least, once we agree on list on a series of "must-haves" for 4.2.0, these could be turned into something similar to your backlog. Maybe we should not discuss tooling now. I think in the end it has to work. Jira is mostly a convenient choice. But we can think of all other sort of combinations. (However we have already a lot of Tools.So I would rather try to reduce those. We can try Bugzilla, but i do not want to start modifying Bugzilla in order to get what we need. 2) I would further propose that we create a new Role - The Product Owner. This is the Release Manager and the community. If someone steps us to do the "secretarial" work of maintaining issues, you have your volunteer; giving him a title is something we normally don't do, but this is irrelevant. yea, we can do so if all are fine by this. 3) If we agree on the Backlist I further suggest that we open up a Jira Issue Tracker. We can keep the Bugzilla Bugtracker for tracking the bugs, and create Issues from it. Or we move to Jira completly. Why do I propose the tool change? Because We can track with Jira Issues, have the Backlog and can use a Project wide Kanban board (replacing in part the Sprints from Scrum) to track Which activity has been started. Where we can create Teams. This won't work. This is tooling that I'm used to using every day, so mine is not a resistance to change. Just, it's clear that nobody does OpenOffice as his day job, so we can't count on being able to assign an issue to someone for example, or on having an issue handled within a certain "sprint". At most, we can hope that people will voluntarily do a very occasional "scrum" like I do for the localization stuff, reporting here when I have some time to work on it and saying where I'm stuck and what would be the next step. The rest looks unrealistic. Let me try to describe the way I think we could make it work. We form the Core teams. A Core team does consist at least of 1 PMC (which can take another Role), 2 Programmer and 2 QA Volunteers and is limited at a maximum of 9 People. Each team is working together and picks Topics from the Backlog in their TeamBacklog of what they believe they can handle within the next month (Just to have a limitation on tasks, but we could also limit as Kanban does it by a fix amount lets say 3 Items). We do setup a Team List for each team. There they can have their "meetings" on weekend each memebr posts a Standupmail, which contains the availability. If he is stuck with issues somewhere. And maybe if he is on track or not. (Transperency, Inspection and Adaptaition are the important Buzzwords here) What does a Core team look into? # Security Bugs would be a candidate. Not all Teammembers need to be on the list thought. # Dependency Migration # Core Code Changes # important Bugfixes (i.e. Crashes) What not? # new Features # nice to have # tooling (except we define something as critical and must have.) I would not change language list, or other activities. However if we have a backlog we could put other stuff there. Like the merchendise Topics. Those are then a free for all volunteers to care in their time. That is the setup I could imagine that could work. Please note setting up the Backlog is a lot of work, because we need to setup the Log in a way that everyone with the right skillset does understand exactly what to do for this task. You will quickly see thats not always easy. Especially in the beginning. I think with that we have a rough structure we can operate on. D
Re: [proposal] going Agile
Peter Kovacs wrote: I would like to propose that we apply Agile development methods as much as we can. Well, "as much as we can" is the key here. OpenOffice is as agile as an elephant. A lot of us use Agile in their daily work activities, and maybe they even like it, but it's a totally different vision from the Apache/OpenOffice way. 1) I would like to propose a Product Backlog / OIL (OpenIssue) List to priorize Issues we need to work on. The most Valueable item comes to the top, the least to the bottom. What Value exactly is is up to discussion. Theoretically, we have a list of issues in Bugzilla with target 4.2.0. Validating them all and/or setting targets will basically give you what you wish. I think Bugzilla has some concept of an issue weight that would more or less allow to prioritize issues with the current tooling, so this can be done. At least, once we agree on list on a series of "must-haves" for 4.2.0, these could be turned into something similar to your backlog. 2) I would further propose that we create a new Role - The Product Owner. This is the Release Manager and the community. If someone steps us to do the "secretarial" work of maintaining issues, you have your volunteer; giving him a title is something we normally don't do, but this is irrelevant. 3) If we agree on the Backlist I further suggest that we open up a Jira Issue Tracker. We can keep the Bugzilla Bugtracker for tracking the bugs, and create Issues from it. Or we move to Jira completly. Why do I propose the tool change? Because We can track with Jira Issues, have the Backlog and can use a Project wide Kanban board (replacing in part the Sprints from Scrum) to track Which activity has been started. Where we can create Teams. This won't work. This is tooling that I'm used to using every day, so mine is not a resistance to change. Just, it's clear that nobody does OpenOffice as his day job, so we can't count on being able to assign an issue to someone for example, or on having an issue handled within a certain "sprint". At most, we can hope that people will voluntarily do a very occasional "scrum" like I do for the localization stuff, reporting here when I have some time to work on it and saying where I'm stuck and what would be the next step. The rest looks unrealistic. if someone wants to stay independant, thats fine. I support that. Freedom is all we want after all. Do you agree? I think it's not about a desire to stay independent, but the necessity to avoid too much structure (despite the name, Agile is a structure, and a very very heavy one). We simply can't afford it. Then, if someone wants to be a volunteer and maintain (in whatever way; Kanban boards are nice, but you don't need JIRA for that; there's plenty of tools for it) something that can visually give the idea of where we are for 4.2.0, I'll be happy with that. And even with calling her the "Product Owner" if she wishes. The impossible thing is to impose a structure on a group like us that has scarce and unpredictable availability, and where people can't just be assigned a task, and where we need community consensus for decisions. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
