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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
