[proposal] going Agile

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[proposal] going Agile

Peter Kovacs-3
Hello all,

  - I would like to propose that we apply Agile development methods as
much as we can. For start we need clarity what task are the most
pressing ones.

  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.

2) I would further propose that we create a new Role - The Product Owner.

The Task of the Product owner is to look that that the Backlog is
maintained. That the Team does understand the issues or Questions are
clarified.

He decides in doubt on the Value of an item. He is not the one who
writes the list. This is our all task.

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.


The hope is that we can gain focus. Even build teams, where more
experienced work with less experience, distribute knowledge by
cooperation. And the hope is that we can guide people.

If you have Questions or did not understand something then please ask.
 From Agile Perspective Development is not a thing that Programmers do
but a lot more people. And I would like that testers, Dokumenters and
all other people who whish to work together understand what this about
how it works.


However I want at the same time no one to pull out of his comfort Zone.
if someone wants to stay independant, thats fine. I support that.
Freedom is all we want after all.

Do you agree?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Andrea Pescetti-2
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.

> 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.

> 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.

> 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.

> if someone wants to stay independant, thats fine. I support that.
> Freedom is all we want after all. Do you agree?

I think it's not about a desire to stay independent, but the necessity
to avoid too much structure (despite the name, Agile is a structure, and
a very very heavy one). We simply can't afford it. Then, if someone
wants to be a volunteer and maintain (in whatever way; Kanban boards are
nice, but you don't need JIRA for that; there's plenty of tools for it)
something that can visually give the idea of where we are for 4.2.0,
I'll be happy with that. And even with calling her the "Product Owner"
if she wishes. The impossible thing is to impose a structure on a group
like us that has scarce and unpredictable availability, and where people
can't just be assigned a task, and where we need community consensus for
decisions.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Peter Kovacs-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

DurgaPrasad Potnuru
+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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Patricia Shanahan
In reply to this post by Peter Kovacs-3
On February 8, 2018, at 5:51 AM, Peter Kovacs <[hidden email]> 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: [hidden email]
>For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Peter Kovacs-3
On 09.02.2018 01:19, Patricia Shanahan wrote:
> On February 8, 2018, at 5:51 AM, Peter Kovacs <[hidden email]> 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.
>> # Start spreading knowledge in our development team.
>> 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.
The tool is not important. It is just a tool that has to serve a
purpose. Important to me is that we change the method we work.
> In my opinion, YAGNI is just as important for process design as for software design.
Thats the principle of lean management. In my opinion we currently work
on this method, but keep the PMO structure that the the project was
build on from the old days. And thats makeing it all difficult for everyone.
> 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.
We had 4 or 5 candidates. So far no one stayed. They had a look and went
off. You can blame all sorts of things. In reality you have only control
over one thing that is you. We do only have the power to change this
project.
If we want that people stay, we need to change. Not other way round.

The question is how we want to change.
I like the family trait we have. I would like to use this trait to make
people stay. Agile teams in my eyes will open a gate for new people into
our community. They start learning some people from the community
quickly and as they work they learn more. Becomming more attached. Thats
why I am suggesting it.

What would you change with the ressources we have to make people stay?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Marcus (OOo)
In reply to this post by Patricia Shanahan
Am 09.02.2018 um 01:19 schrieb Patricia Shanahan:

> On February 8, 2018, at 5:51 AM, Peter Kovacs <[hidden email]> 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? ;-)

But Confluence can bring us some overview. We can structure similar BZ
issues to packages and then we can work on them.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Marcus (OOo)
In reply to this post by Andrea Pescetti-2
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.

Kanban would be nice.

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.

My 2 ct.
(also with my years of experience as Scrum Product Owner)

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Peter Kovacs-3
In reply to this post by Marcus (OOo)
Migration would be done by infra. They wrote up everything need to know:

https://wiki.apache.org/general/ApacheBugzillaToJiraMigration


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.

I know that you complained onec there are so many differnt links to note
and tools that we have in our arsenal.

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.

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.

That would mean 2 more developers. Propably. Maybe they quick because it
is frustrating to build OpenOffice. *ROFL*



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.

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Peter Kovacs-3
In reply to this post by Marcus (OOo)

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?
(Nooooo.... ;) )
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Patricia Shanahan
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 <[hidden email]> 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? (Nooooo.... ;) )
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Damjan Jovanovic
In reply to this post by Marcus (OOo)
On Sat, Feb 10, 2018 at 12:05 AM, Marcus <[hidden email]> wrote:

> Am 09.02.2018 um 01:19 schrieb Patricia Shanahan:
>
>> On February 8, 2018, at 5:51 AM, Peter Kovacs <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Marcus (OOo)
In reply to this post by Peter Kovacs-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Marcus (OOo)
In reply to this post by Peter Kovacs-3
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?
> (Nooooo.... ;) )

We use Confluence already, so whay not to continue.

<sarcasm>
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.
</sarcasm>

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Patricia Shanahan
In reply to this post by Peter Kovacs-3

> On Feb 9, 2018, at 20:05, Peter Kovacs <[hidden email]> wrote:
>
>> On 09.02.2018 01:19, Patricia Shanahan wrote:
>> On February 8, 2018, at 5:51 AM, Peter Kovacs <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Peter Kovacs-2
How can I build only core package?
I am only aware to build everything, or a certain range of modules, or I can build explicit one module.

I do not want to take away the ability to build all in one step.
But I think if you are only rebuilding core it saves you a lot of time. And if you can check  if there is an effect beyond package boarders, it helps you to avoid the issues that had happened in 4.1.5.
Just thinking. I said I am sorry was to hasty in this.

Am 10. Februar 2018 14:46:01 MEZ schrieb Patricia Shanahan <[hidden email]>:

>
>> On Feb 9, 2018, at 20:05, Peter Kovacs <[hidden email]> wrote:
>>
>>> On 09.02.2018 01:19, Patricia Shanahan wrote:
>>> On February 8, 2018, at 5:51 AM, Peter Kovacs <[hidden email]>
>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: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Peter Kovacs-3
In reply to this post by Marcus (OOo)
On 10.02.2018 13:26, Marcus wrote:

>
> 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".
ok, lets try this.

However I think we should keep an eye on bandwith needs. That is a good
point from Damjan. We are not only a first world thing. We are for
everyone and everyone that is willing should have a chance to participate.
I have seen also in the discussion that we would like to support other
Open Source Projects if we can. We should therefor concider that Jira is
only a intermediate solution, to be used until we have a replacement in
Bugzilla.
Do you agree with my observation?

> 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.
My priority is to get a better overview of what needs to be done and
that we work better together, so we have a better chance in including
new people.
I will have an eye on topics what volunteers need. I am looking forward
that we break those eggs one after another together.

I think I did this one wrong, because I started of what I would like to
do and got into a confrontation role, which I did not want to. Tooling
and Scrum Framework was not in my center of my goals but It was very
important in the discussion.
I am a real slow and bad learner. I hope no one takes this personal. I
am imaptioned. I apologies to myself and to all others for my uttelress
clumsyness.

I thank you all for the open discussion and the shown courage to speak
up. I believe that these are values that make us work together. Even
without Scrum. ;) I hope maybe that others are inspired by this and
speak up to.
You are all Welcome!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Dave Fisher
Hi -

Thanks Peter for driving this topic. I don’t think we all agree, but we can (a) try to advance our project organization and (b) acknowledge how we are using the many tools we already use.

> On Feb 12, 2018, at 1:15 PM, Peter Kovacs <[hidden email]> wrote:
>
> On 10.02.2018 13:26, Marcus wrote:
>
>>
>> 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".
> ok, lets try this.
>
> However I think we should keep an eye on bandwith needs. That is a good point from Damjan. We are not only a first world thing. We are for everyone and everyone that is willing should have a chance to participate.
> I have seen also in the discussion that we would like to support other Open Source Projects if we can. We should therefor concider that Jira is only a intermediate solution, to be used until we have a replacement in Bugzilla.
> Do you agree with my observation?
(1) Bug/Issue Trackers available from the ASF.
(a) Bugzilla - OpenOffice has a dedicated instance as does SpamAssassin while many projects share a third.
(b) JIRA - Atlassian has provided a free license to the ASF. Not all plugins may be available. If one is missing then it will need negotiation.

(2) Wikis available from the ASF.
(a) MediaWiki. This wiki is supported by the AOO PMC and came over as a legacy from OpenOffice.org.
(b) Confluence. (Again Atlassian provided free license) This is hosted by the ASF and the project has two available for organizing various tasks. We used these pretty extensively during migration to organize work.
(c) MoinMoin. Also hosted by the ASF - a more old school wiki. Used by the Incubator and others.

>
>> 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.
> My priority is to get a better overview of what needs to be done and that we work better together, so we have a better chance in including new people.
> I will have an eye on topics what volunteers need. I am looking forward that we break those eggs one after another together.

My suggestion is to use tools we already have. A wiki seems correct to me. I would suggest Confluence, but that is my personal preference. We already have tools deployed. I think we just need to manage a table from time to time. Periodically we can “Scrum” on dev@ over the status.

>
> I think I did this one wrong, because I started of what I would like to do and got into a confrontation role, which I did not want to. Tooling and Scrum Framework was not in my center of my goals but It was very important in the discussion.
> I am a real slow and bad learner. I hope no one takes this personal. I am imaptioned. I apologies to myself and to all others for my uttelress clumsyness.

Nothing to forgive since you are proceeding with a rational discussion. So we are clear you are looking to have a high/medium level overview of tasks and status towards goals. I think this can be a table in a wiki.

>
> I thank you all for the open discussion and the shown courage to speak up. I believe that these are values that make us work together. Even without Scrum. ;) I hope maybe that others are inspired by this and speak up to.
> You are all Welcome!

Bitte! (Did I use that correctly?)

Regards,
Dave

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Marcus (OOo)
In reply to this post by Peter Kovacs-3
Am 12.02.2018 um 22:15 schrieb Peter Kovacs:

> On 10.02.2018 13:26, Marcus wrote:
>
>>
>> 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".
> ok, lets try this.

great

> However I think we should keep an eye on bandwith needs. That is a good
> point from Damjan. We are not only a first world thing. We are for
> everyone and everyone that is willing should have a chance to participate.
> I have seen also in the discussion that we would like to support other
> Open Source Projects if we can. We should therefor concider that Jira is
> only a intermediate solution, to be used until we have a replacement in
> Bugzilla.
> Do you agree with my observation?

Sure, we can try to participate in other projects. However, I thing we
have much to do in our own project.

>> 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.
> My priority is to get a better overview of what needs to be done and
> that we work better together, so we have a better chance in including
> new people.
> I will have an eye on topics what volunteers need. I am looking forward
> that we break those eggs one after another together.
>
> I think I did this one wrong, because I started of what I would like to
> do and got into a confrontation role, which I did not want to. Tooling
> and Scrum Framework was not in my center of my goals but It was very
> important in the discussion.
> I am a real slow and bad learner. I hope no one takes this personal. I
> am imaptioned. I apologies to myself and to all others for my uttelress
> clumsyness.

Don't worry too much. Many proposals need to be discussed before coming
to a common understanding - and an agreement.

Thanks for starting this discussion and to try to improve the project
with new ideas.

> I thank you all for the open discussion and the shown courage to speak
> up. I believe that these are values that make us work together. Even
> without Scrum. ;) I hope maybe that others are inspired by this and
> speak up to.
> You are all Welcome!

One good thing in Scrum is: fail fast (do something and stop when it's
not working before wasting more money/time).

So, let's try to implement some ideas and watch closely if it's worth
the effort.

@all:
What do you think is the first topic we should start with?

Marcus

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proposal] going Agile

Andrea Pescetti-2
Marcus wrote:
> @all:
> What do you think is the first topic we should start with?

I think the only reasonable way forward is that Peter chooses one of the
many available tasks (digital signatures? Java 9 support? MSVC update?
.docx export? you name it) and experiments the workflow limited to it.
Even if it is a relatively small project, one can decompose it in many
subtasks: none of these is "too simple" for an experiment.

This way the rest of the project can continue as always, while we have a
proof of concept that can involve volunteers and so on. Once the proof
of concept is completed, it can serve as a model for expanding it.

Otherwise my feeling is that we will waste too much time discussing the
theory and making it perfect, but getting nowhere in practice.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12