On 09.02.2018 01:19, Patricia Shanahan wrote:
On February 8, 2018, at 5:51 AM, Peter Kovacs <pe...@apache.org> 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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to