On Wed, Dec 11, 2013 at 10:38 AM, Andrew Grieve <[email protected]> wrote: > Joe - would you be willing to write the blog post on Cordova's blog instead > of a personal blog? Each cordova blog post does have an author with an > optional link.
If I have to, I think we should syndicate instead so we don't copy/paste content. > I think having things on Cordova's blog rather than personal / downstream > ones makes things more trusted & discoverable. I disagree. We should have Cordova's blog syndicate other known blogs. I don't think anyone actually reads the Cordova blog. I haven't until today. Joe > > > On Wed, Dec 11, 2013 at 1:27 PM, Joe Bowser <[email protected]> wrote: > >> On Wed, Dec 11, 2013 at 10:23 AM, Andrew Grieve <[email protected]> >> wrote: >> > Yep, my main concern is communicating what's changed to our users for >> > releases. Whether this file actually exists, or when it's updated, I care >> > less about. >> > >> > Joe - if you don't think a single blog post is a good way to >> communicating >> > this, what's a good alternative? Should we have each platform write a >> blog >> > post as a part of the release instead of release notes? >> > >> >> Yes, because until recently that's what we did. Shaz wrote the iOS >> one, and either Simon or I wrote a blog post about Android. These >> would then be syndicated and put on the phonegap.com blog. We used to >> have a perfectly good solution to this problem which went away roughly >> around when 3.0.0 came out. This mostly went away because of time >> constraints and the fact that my own blog sucks ass and needs to be >> migrated to a real server. I think we need to go back to this. >> >> Also, this is a good way for people to get exposure and get their name >> out there, so there's way more reward for doing this than just writing >> RELEASENOTES.md which will be buried in the release and may or may not >> be read. >> >> > >> > On Wed, Dec 11, 2013 at 11:05 AM, Josh Soref <[email protected]> >> wrote: >> > >> >> Michal wrote: >> >> > when doing a release, you usually have to make a >> >> > mental note of what is worth testing, which usually means going >> through >> >> the >> >> > changelog anyway, which means it isn't really adding serious time to >> the >> >> > release process. >> >> >> >> > However, this shouldn't be codified into our processes, >> >> > and should be the responsibility of whoever is doing the blog post, >> not >> >> > whoever is doing the release, and those two aren't always the same. >> >> >> >> +1 >> >> >> >> One problem is that the release blog seems to be pro forma and hurried. >> >> >> >> I've written release notes with blog entries. Doing them well is >> >> worthwhile. >> >> >> >> A few things that can help: >> >> 1. Tagging issues at filing / analysis / resolution with a release note >> >> indicator (yes, no) >> >> 2. Working on the release notes before the release process finishes - >> you >> >> probably already have 90% of the release fixes known a few days before d >> >> day. The last fixes can be yes/no as they're committed. >> >> 3. It's important not to have "Fixed x; backed out fix for x". People >> >> reading release notes don't care about the process between the previous >> >> release and now, they want a clear indication of what has actually >> changed. >> >> >> >> >> >> > So lets remove the requirement, and I guess the RELEASNOTES.md file >> from >> >> the repos? >> >> >> >> +1 >> >> --------------------------------------------------------------------- >> >> This transmission (including any attachments) may contain confidential >> >> information, privileged material (including material protected by the >> >> solicitor-client or other applicable privileges), or constitute >> non-public >> >> information. Any use of this information by anyone other than the >> intended >> >> recipient is prohibited. If you have received this transmission in >> error, >> >> please immediately reply to the sender and delete this information from >> >> your system. Use, dissemination, distribution, or reproduction of this >> >> transmission by unintended recipients is not authorized and may be >> unlawful. >> >> >>
