Optimizing release development workflow for Neos/Flow

[aertmann (Aske Ertmann)]

@radmiraal

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.

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.

@radmiraal

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.

Thanks for clarifying.

@radmiraal

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.

Sounds good to me.

@radmiraal

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’

You mean in Planning Neos 2.1 / Flow 3.1 - #2 by aertmann? All those are just possible tasks to choose from.