On February 8, 2018, at 5:51 AM, Peter Kovacs <pe...@apache.org> 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 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. >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. DoDs, DoR >would be nice but fine. We can also make a bazzar as a "meeting" where >the Tasks get distributed. Something like this. >The nice thing is that we are close enough to scrum that we can operate >with a mac core teams of 3 until the structure breaks. And we could look >into Scrum Nexus in order to scale beyond this. >And because we work scrum like, a Company that shows up could easily be >incooperated by forming a true scrum team. So we are flexible in this >way, too. (And we would always have the slow moving Volunteer teams as a >base of operation) >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org
