Meeting notes on OpenWrt announce / communication organisation

Date: 21 November 2019

Participants: Baptiste, Hauke, John, Rich

Meeting location: Mumble

Goal: sketch out and write down a proposal on how to organize OpenWrt announcements and communication. The proposal will then be discussed on openwrt-adm.

• Rich : what about the schedule of the current release?
• Baptiste : the goal is more about communicating the changes, rather than deciding things. E.g. releases notes, security announcements, major development changes
• John : it's important to have people maintaining part of the projects for a long term (several years).  E.g. documentation, huge progress in previous years
• Rich : it's probably not that hard to find people willing to help writing release notes, etc
• Baptiste : what's important is, who feels responsible? who starts the initiatve and makes sure that things happen? People can volunteer to manage release notes & such for a given release, and somebody else for the next release, etc (rotation)
• Rich : agreed, and it allows to learn from each other. What about a release manager?
• John : we had release managers in the past, but it was hard: people don't necessarily have the time, and then get flamed for not doing the job
• John : we can imagine a “manager” just for the release notes
• Rich : how much work does a release represent?
• John : before, one person working 6 to 10 weeks full-time. Now we have buildbots and automation, so it should be less. Main problem, nobody is happy with the release schedule (“I want this feature in” vs. “I don't care about this feature and I want a release sooner”).
• Hauke : think about it in terms of offloading the people handling the release: post list of critical issues on the mailing list, triage bugs, write release notes
• Baptiste : the group takes the decision, and then can delegate some of the practical choices to somebody
• John : since the reboot, the structure is completely flat, we don't want first class vs. second class citizens (= people with more power than others)
• Rich : the group can decide on things (“include feature X in the next release”), and then designate somebody to be “in charge” for actually doing it
• Rich : writing release notes is a “bounded task”
• Baptiste : “bounded tasks” are good, because a volunteer can feel conformable doing it. But who gets to decide 
• Rich : after writing the release notes, go back to the group to get feedback
• Baptiste : what happens if you get don't any feedback? Is it because everything's perfect, or because nobody cares?
• John : just start doing some stuff (e.g. write release notes), and tell relevant people (i.e. jow) that you are doing it, and all will be fine
• Hauke : what's important is not waiting for others to do things and start doing them
• Hauke : also important, documenting what tasks/help are needed
• Rich : how do we make Jow's life easier by offloading some work?
• John : expectations about help are probably low, which is why the “usual suspects” end up doing everything themselves
• John : how to help: just tell Jow that you want to help with, with a timeline

It may help to clarify what's needed for a release, so that it's easier to know how to help.

• when to branch (difficult part!)
• when to start building (difficult part!)
• starting the build
• monitoring the outcome of the build
• some runtime testing
• writing release notes
• documentation on new features
• announcements

Existing documentation:

1. How to create a major release
2. How to make a service release
3. How to create a minor release

Baptiste : improve the documentation so that it's very clear which tasks needs to be done and who can deal with them (makes it easier to participate) → TODO: ask jow to make sure we don't forget anything, and document it

John : will call jow to summarize the meeting

John : when working on the release notes, inform Jow and John to avoid having several people working on the same stuff

Publish these meeting notes in the wiki (TODO Baptiste)

Hauke makes sure that Baptiste can edit the whole wiki.