First, the analogy of splitting the canvas into 5 doesn't work. Even though you're working on a single feature, you can see the whole canvas and (one would assume) you're communicating to make sure that the changes are harmonious.
That is the idea of each project, then reality comes and some people don't even listen on the daily standup much less take a look at slack or whatever they just want to be left alone and code.
Second, feature toggles are a bad idea in my opinion. They basically translate to increasing the cyclomatic complexity because someone can't decide whether a feature should be on or off.
If the feature is marked as delivered then it should be on unless it creates a critical bug on production.
The real problem isn't branching, it's indecision and poor planning.
You will have those you want it or not therefore I prefer a system more resistant to it.
I could very easily see four or five half baked features becoming a testing and maintenance nightmare. If you do this for any length of time, your "bitfield" of features will be a lot more than 4 or 5. Good luck changing things when you realize a half baked feature needs a design change in order to complete and you have a few other half baked features to deal with.
Don't bite more than you can chew. Why start 5 new features if your team can only handle 2 per sprint?
Based on personal experience, I would say, don't give in. Instead push for change, hard. Sometimes you will hit a brick wall and will have to move on. But then you find a team (and a manager) that's a joy to work with and work becomes a pleasure.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That is the idea of each project, then reality comes and some people don't even listen on the daily standup much less take a look at slack or whatever they just want to be left alone and code.
If the feature is marked as delivered then it should be on unless it creates a critical bug on production.
You will have those you want it or not therefore I prefer a system more resistant to it.
Don't bite more than you can chew. Why start 5 new features if your team can only handle 2 per sprint?
It sounds like the problem you're experiencing is lack of communication and agreement. Code isn't going to fix a human problem.
I suggest you tackle the problem at the layer it manifests instead of trying to reinvent a square wheel at a lower layer.
After years of working on several companies and projects the only thing I saw in common were two:
If you have some suggestions on the communication part please tell.
Based on personal experience, I would say, don't give in. Instead push for change, hard. Sometimes you will hit a brick wall and will have to move on. But then you find a team (and a manager) that's a joy to work with and work becomes a pleasure.