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: Printing Envelopes, Sent, Friday. 2-9-18.
Sent from my mobile device. > On 10 Feb 2018, at 6:03 pm, Peter Kovacs wrote: > > Hi OpenOffice User List, > > > I pass this request to you. > > If there are problems that we have to solve by coding, You only can solve problems by coding if you can replicate the problem and have identified the cause of the problem. So the user should first test if he can print envelopes from other applications. So let him export the file to PDF and see if he is able to print from Acrobat. Other option is to check if he can print to another printer and he said printing To his Epson printer worked fine. My guess is the problem is with the installation of his printer. The moral is “ Don’t fix what is not broken” > > please send us a note to the dev list or open a bug. > > > Thanks for your continous effort to help users! > > > All the Best > > Peter > > >> On 09.02.2018 16:29, Ddardanell wrote: >> Hi, I just bought a new Brother All in one Printer. >> >> Model # (L8900cdw), and it works >> Fine but I can't find out how to >> >> Print Envelopes?. Now, when I >> Had my Epson ink jet printer >> >> There was no problem, but I can't >> Seem to find the Option now >> >> With the new printer too print >> Envelopes?. >> >> And I believe I have version 4.1.5. >> Can you take me by the hand, and >> >> Help me figure out what I am doing >> Wrong?. >> >> Thanks so much, and I look forward too your response. >> >> Sincerely, >> Don G Dardanelli >> 1168 Pembridge Dr. >> San Jose, California. 95118 >> >> PH: (408-202-4624) >> E-Mail: (ddardan...@aol.com). >> >> Sent from my Sony Xperia™ smartphone > > > - > To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org > For additional commands, e-mail: users-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 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