Author: intrigeri Date: To: Public mailing list about the Tails project Subject: Re: [Tails-project] writing the release notes for 1.3
Hi,
sajolida wrote (28 Feb 2015 13:04:01 GMT) : > intrigeri: > But I'm not sure it adds more work for the doc
> writers. It would add more pressure instead maybe.
Yes, indeed that's what I meant :)
>> 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?
To sum up:
* Anyone at ease with Git could improve these draft snippets
pre-merge, if the branch developers communicate with them.
* Anyone at ease with Git could improve these draft snippets on the
testing branch post-merge.
* Anyone not at ease with Git could improve the aggregated release
notes draft on a blueprint, between the RC and the final release.
> 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.
Hence the idea of having an online ikiwiki built from the testing
branch, or similar, that I suggested somewhere (on this thread,
perhaps; it was a while ago, like yesterday, so I don't remember :)
But even without this, the proposal we're discussing already enables
*lots* more people to participate, so IMO it's a bonus,
non-blocking feature.
>> 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.