openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DurgaPrasad Potnuru <>
Subject Re: [proposal] going Agile
Date Thu, 08 Feb 2018 06:13:02 GMT
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.
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message