Re: [Tails-project] writing the release notes for 1.3

intrigeri:
> The initial idea was: before a branch is proposed for merging, the
> developer who has been working on it reaches out to doc writers to get
> the draft end-user doc and release notes snippet reviewed, and
> possibly improved. I believe that for a great part of the major
> changes that are worth documenting in the release notes, this
> communication already has to happen for the end-user doc polishing
> anyway. So it adds a little bit overhead, but not that much.
>
> Now, I can see that this would add more work for doc writers, and
> could block features from landing into the testing branch. Given how
> you (sajolida) currently 1. are practically the only person who has
> the commit-bit for non-trivial changes to the doc, and 2. already have
> a hard time dealing with all the doc things you feel you have to
> review/improve before they get merged — perhaps it's not the best
> idea ever.

Sure, if I understand you correctly, the issue here would be to have
code not merged or merged too late because it lacks release notes
snippets for example. But I'm not sure it adds more work for the doc
writers. It would add more pressure instead maybe.

> So, instead, perhaps we can make it so a *draft* release notes snippet
> is mandatory for any branch carrying changes that might be worth
> mentioning in the release notes. It's left at the discretion of the
> reviewer to ack/nack whether a given branch can freely skip this
> requirement. This draft release notes snippet could also be a good
> place for developers to dump all the info they think you might need to
> write a good piece of text about their shiny new feature.

Agreed.

> And then, instead of having a week for making the release notes as
> good as you would like (before the RC and the actual release), you or
> anyone else interested can incrementally work on it during the entire
> release cycle.

Agreed.

> Even better: this does *not* conflict with the proposal of giving more
> exposure to the release notes improvement effort: the draft release
> notes, once automatically assembled from the snippet at RC time, can
> be published on a blueprint as you suggested, etc.

Right. It's important to find a process that's technically accessible to
people like BitingBird for example. If I understand correctly your
proposal, those contributors would be improving the draft snippets once
they landed in the testing branch, right?

The problem we saw this time is that people working on the release notes
from a blueprint on master didn't have access to the documentation in
testing to understand the features and internal links were broken.

> So it seems to me that this would lighten the RM workload, improve our
> time-to-release, and allow doc writers to spread their work on the
> release notes over the course of the release cycle. Catchy, uh? :)

I like it.