<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 19, 2010, at 6:08 AM, <a href="mailto:exarkun@twistedmatrix.com">exarkun@twistedmatrix.com</a> wrote:</div><br><blockquote type="cite"><div>In particular, I'd like to draw everyone's attention to the requirements </div><div>for news fragments. Since we introduced this part of the workflow, the <br>review requirements for these has been a little unclear. Many reviewers <br>haven't required that the news fragment be reviewed (that is, if it was <br>missing, they would say "Please add a news fragment and then merge.") or <br>haven't kept the guidelines these files in mind when reviewing them.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>Can you point to some specific examples in the current release, and note what they should have been?</div><br><blockquote type="cite"><div>I'd like for this to change. Informative, consistently written news <br>fragments result better information being available to users when we do <br>a release. This is a very simple part the development process but <br>effort here has a disproportionately large effect on the perception of <br>Twisted.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>Generally speaking, I agree. But I think we need to nail down a very specific proposal if this is to improve. What should reviewers be looking for in a good news fragment? What are pitfalls to avoid? Asking reviewers to look at something that isn't clearly spelled out may just result in more churn in reviews; I'd hate to see an extra round trip on a ticket because of an oxford comma placement in the news fragment.</div><br><blockquote type="cite"><div>If the guidelines for news fragment content on the review process wiki <br>page are unclear or insufficient, please complain and we can work on <br>improving the weaknesses.<br></div></blockquote></div><br><div>There's very little in the way of stylistic guidance on this page.</div><div><br></div><div>For one thing, I suspect there were a lot of fixes which could have been a '.misc' but were instead a '.feature' or '.bugfix'. We need some better guidelines for what exactly constitutes a change that is interesting to users.</div><div><br></div><div>It advises that a single sentence be written about a change to an FQPN. This is hard to do well for new features. For example, "twisted.internet.endpoints now ... exists" doesn't really scan, and doesn't really emphasize the importance of the feature relative to some of the other small fixes which have been added. I feel like I probably wrote too much of a dissertation in 1442.feature and not enough of a description in 990.feature, but I don't know what would have been better. If you know something should be a highlight, how should that be indicated? Should the highlight text be different from the news fragment text?</div><div><br></div><div>For complicated bugfixes it's also sometimes awkward, because it's hard to briefly describe a subtle, but still potentially important change in behavior.</div><div><br></div><div>A list of 10 examples of "good" feature descriptions and "good" bugfix descriptions would go a long way towards improving this.</div><div><br></div><div>Thanks for raising the issue though. I would also like to see a more coherent NEWS file for 10.2 :).</div><div><br></div></body></html>