Hello,
I thought I should open a discussion about this. I mentioned in last week's
meeting that we spend a lot of time planning and not that much executing.
The highlight of this is we have a 1.5 hour weekly meeting where nothing
can be decided since decisions are done on this mailing list.
In a community like this. If you take away everything, but the bare
minimum. There really only exist the things that have a PR and what is
merged in.
Why is a plan not included in the bare minimum? A plan is a wish. For a
wish to become a reality it needs a contributor ( single or a team ) and
work hours to get done ( no getting hit by a bus, people changing jobs,
company shifting interests or closing down a contributing team ). Only when
the plan has a PR, everything green and working, does it exist for the
community. ( Merge is just a matter of a mouse click. )
Few types resulting in a PR:
1. You can propose something. Ask for feedback. Make a good plan. Get
everyone to agree. Make a PR.
2. You can propose something... Make a PR and the PR is nothing that was
agreed upon.
3. You can propose something. Nobody wants it. Make a PR
4. You can just make a PR with no warning.
What type is best? Depends.
It is possible to have several plans competing. First one having a PR
usually wins.
I am bringing these bullet points up just to give a heads up.
- For a good while everything was led top down at Red Hat. In an
environment like that it is easy to make long term plans. In the current
setup, anything that goes past 3 months is a dream. Any plan is a wish
until PR, any PR is a proposal until it is merged.
- PR contains what the contributor decides it contains. It is of course
beneficial to signal the change early, implement what is agreed on,
propose, vote and so on. However if something needs to get done, there is
only one person that is willing to do it. Then it is up to the community to
take what is offered or live without.
- A contributor is the lead for the work and planning leading to a PR.
- Contributor can be a group of people
- PR contains what the contributor decides it contains.
- Plan is formed by the contributor
- Contributor can take in suggestions
- Plan is executed by the contributor
- PR is delivered by the contributor
- The contributor can not alone decide if the PR is merged. This is
up to the community and therefore we get "separation of powers"
- If you disagree on something.
- You can offer opinions, these can be ignored.
- You can offer help ( better way, still might also be ignored )
- You can make a completely alternative implementation
- You can also slow down the process of getting things done by
stalling it in many ways. Try not to be that person
- Too much planning will drive contributors away
- Too much critique will drive contributors away ( maybe it can be fixed
later )
- The best plan loses to the solution that has been implemented
- Getting everyone to agree on something is impossible
- Getting everything perfect on the level where even one of us is happy
is impossible
- Each one of us is QA, PM, HR, contributor, a customer and a king/queen
of their own work.
- There is no higher level that can
- Settle arguments
- Decide when a plan is complete
- Decide who does what
- Order anyone to do anything
- Order anyone not to do something
- We need to be comfortable with conflicts
- Do not trust work planned by a contributor will be delivered
- Do not trust PR contains what was planned
- A working community is based on trust. ( There is a balance of trust
and not having it.) Not every PR has to be agreed by everyone
- Code wins
- Getting things done wins
Now these are not rules I am proposing. This is how it works with the
current setup. It might feel like a wild west, because it is. It is however
how Open Source projects work when they are actually open. This is more or
less how the early days of KIE were ( different branding back then ),
before everyone in the community was working for the same company.
I am bringing this up since I see a few items stuck on planning and we
needed them ages ago. We have contributors that can act, but getting the
plan perfect is in the way. The contributors can just say this is enough,
implement and this will drive the change forward. For those opposing this.
The options you have are listed above.
Toni Rikkola
Community member sponsored by Red Hat during days
Community member sponsored by Kalsarikännit during nights
