+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" <[email protected]> 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. > > 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: [email protected] > For additional commands, e-mail: [email protected] > >
