Recommend new communication process for releases #200
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We have seen that the community would prefer to vote on releases earlier on in the process rather than at the end. But there is also good reason for this, in that we are not asking the community to dictate the content of our releases, rather we want them involved in the process of the deployment of the release. Of course, we appreciate input and we should definitely open the content of our releases up to the community as early as possible and ask for their feedback or input, and we should also reiterate to them that they are always free to leave GH issues on relevant repos and flag for an upcoming release.
Anyway long story short I will put together a new recommendation for process of releases and circulate and let's see if we can implement something that works better for everyone.
Here is the draft:
https://docs.google.com/document/d/1NQ5-aQAFFppYICIUy_8JMJHGH4-gc8CfMUsYZhQjuWc/edit
Passed around for feedback from comms team and stakeholders. Ideally need:
Waiting for feedback, this will surely not be completed in this sprint. I will move to the next one and put in blocked for now. We should be having a meeting on 3.15 next Tuesday so will update after that.
Thabet has a strong opinion here that the community should not vote at all on tech developments. We'll have to discuss next week.
As part of #204 please also include in that post or create a new post to clarify the release process and why we do things the way we do it. Can use the draft above, it's a good start, but no need to go into so much detail or background.
This is being incorporated into the 3.15 release