Looking back at the past release cycles, every release has taken longer than expected and been difficult to finalize. To gain momentum we need to change our workflow.
Let’s collect ideas and start a discussion how this can be achieved.
I’d suggest to collect ideas for every release and then narrow them down to a few ones and vote on them. This is to reduce limit the amount of different features being worked on so it’s easier to finish. Additionally we as a team need to work together on top prioritized features instead of everyone pushing their own agenda. It will also make it easier for everyone to see what’s planned and how to help with those tasks. This will mean a change in our currently anarchist way of working and thus it’s harder to influence the direction. However it will mean that the features that are the top priority for the product in general will be the focus.
We need this in order to deliver manageable releases and prevent the inefficient and slow work mode we’ve had so far. If a feature is too big to fit into one release, it either has to be split up in smaller merge-able sizes or be developed in a separate feature branch that those working on it have responsibility to keep it rebased on master.
In general the concept of “feature-freeze” hasn’t worked out very well and I’d suggest to get rid of it. Rather the selected tasks should determine when a release is finished. All smaller tasks that won’t justify is a release “feature” can go in until the release features are finished and beta phase is initiated.
In practice we should create epics/stories for those tasks and add them to the sprint board in Jira.
1 Like
To get this thread rolling I just drop it in: I disagree to Aske 
(partly at least)
I don’t care that much about personal agenda’s being pushed, because we’ve always stated that it’s fine to work on personal idges and that’s what drove us all to contributing to begin with. If we feel like not being in a flow we should have a look at how stuff goes. Honestly, having far too big goals for releases, stuffing everything in it and change concepts even in beta phase is a no go to me. People decided to work like that, and it drained energy and stopped the contribution flow imho.
So maybe we should work on just the 1, 2 or 3 highest prio features of the backlog. Everyone working on something else is also fine, but let’s get in a flow and decide before feature freeze what features (which are in branches and not halfdone and undocumented in master) are done done and get into the beta phase…
If we start planning goals too high again we all know where this will end, so let’s finally get to this ‘release often’ thing, be it a patch release, a minor release or major release, but let’s release! Imho the team currently somehow makes everything bigger and bigger and stuff grows to a size we’re not able to manage. So let’s pick some smaller cherries for next release and see how that works out… Because like Aske mentioned: the github move will consume quite some time anyway… be it for the release scripts, support, tuning, finalizing or whatever…
1 Like
Hey Rens, thanks for your input. Not sure if we disagree, let me elaborate.
It’s of course fine to work on smaller personal itches, however we as a team need to focus on a few bigger tasks together per release. Otherwise those things will be too difficult to finish. It’s about collaborating more on prioritized tasks instead of everyone doing their own thing, trying to get it finished which is usually difficult to do. There’s a lot of aspects involved that need to covered, often more than one or two people can manage on their own. Also reviews are needed to finish things, which have always been a bottle neck. What I want to avoid is things going into the master branch without being finished (has happened a lot in the past), making it difficult to release because the responsibility is then shifted to the team and release manager to finalize them in order to release. Instead selecting what the team sees as the top priorities and working together on finalizing and polishing (testing/stabilizing/documenting), would avoid such situations. Another point is that it allows communicating and marketing the releases much better.
If someone is not interested in the top priority features for that release, one can work on something else that can then get into a later release or the release when it’s finished. If a feature is almost done, there’s a high probability that it’s easy to that voted as a high priority feature for a release.
Just to be sure, are you suggesting all features are developed in feature branches and not merged into master until we reach feature freeze and then decide on what’s available and manageable or?
That’s kinda the point, to prioritize and select a few features that aren’t too large to achieve. If it’s a really big one, we should create a release just focussing on that task. Then the next release would include other features people could work on simultaneously.
I can say that this approach has really worked well for the TYPO3 team since they started working like this and planning their releases and getting the team to work together on those priorities selected for the releases.
It should be possible for us to find a way that everyone can work on something they find useful, finishing important bigger features as well as improving the product overall with smaller improvements in addition.
1 Like
I think in general we agree here, but I’d really opt for having just 1 or maybe 2 of those features then. And we should (as a team) also be able to label a task as ‘too big to handle by one’, meaning someone could do the heavy lifting of a feature alone (code wise), but always has a buddy / actively communicates about status so we can not have “submarine projects” that dive under and appear in the wrong form / too late.
Nope, I mean what you also mention in the first paragraph of your reply. A feature should not get into the master branch if it does not meet the definition of done.
And then we can discuss what the definition of done would be, and that’s imho never the final, cleanest, enterprisy and shiny end result of the feature… But it’s a documented, working and stable minimal viable product.
This is what I can’t really match with the long list you suggested for the features. A ‘few’ should be a ‘few’, not ‘a few and a few’ 
This came in via the Atlassian newsletter yesterday, thought I’d drop it here. Some interesting stats, maybe…
1 Like
Fully agree here, don’t want to take on too many things. We just need to find the right balance of allowing contributors to work without being blocked. So depends on size of tasks and how many are interested in collaborating on them. But in general max 2 bigger tasks, preferably 1 per release would be ideal.
Thanks for clarifying.
Sounds good to me.
You mean in Planning Neos 2.1 / Flow 3.1 - #2 by aertmann? All those are just possible tasks to choose from.
Following up on this topic, see the outcome of a related discussion Planning Neos 2.1 / Flow 3.1