Will this mean we will be discussing blog post curation stuff on dev@cordova.apache.org ?
On 8/6/13 10:46 AM, "Tommy Williams" <to...@devgeeks.org> wrote: >+1 from me as well. > >I like the idea of official posts looking official as well as the side >effect of third party posts getting the traffic benefits. > >- tommy >On 7 Aug 2013 03:44, "Ian Clelland" <iclell...@chromium.org> wrote: > >> +1. That's a good approach to separating them, and should encourage >> third-party authors to submit pieces -- knowing that Apache will drive >> traffic to their site. >> >> >> >> >> On Tue, Aug 6, 2013 at 1:35 PM, David Kemp <drk...@google.com> wrote: >> >> > +1 for Michals approach >> > >> > >> > On Tue, Aug 6, 2013 at 1:27 PM, Michal Mocny <mmo...@chromium.org> >> wrote: >> > >> > > I'de like to make a proposal about how we go about publishing >>certain >> > blog >> > > posts. I think this is a good practice for Organizational-type >>blogs >> to >> > > clearly identify posts which are (1) genuinely origination from the >> > > organization, vs (2) those which are just being curated from within >>the >> > > community. This is already widely accepted practice on many other >> blogs >> > as >> > > well as on Twitter, and I think already the strategy that PhoneGap >>blog >> > > uses. >> > > >> > > Basically: >> > > (1) If the content has to do with cordova-core, i.e. announcing >> releases, >> > > or publishing guides, etc., we should publish the full text >>directly on >> > the >> > > cordova Blog (by whichever author), as-if written by the >>organization. >> > > (2) If the content was written by a contributor and is worth >>curating >> for >> > > the whole community, but is not really core ie. non-core plugins, >>dev >> > tips, >> > > research, opinion-pieces, statistics, etc., post a short >>description, >> > > perhaps adding a document-snippet, but then link to the externally >> hosted >> > > content, making it clearly not written by the organization. >> > > >> > > I think this makes it both easier to identify those posts which are >> > really >> > > organizationally important, as well as giving us a way to post >>things >> > that >> > > otherwise maybe would not have made the cut. >> > > >> > > WDYT? >> > > >> > > -Michal >> > > >> > > >> > > On Tue, Aug 6, 2013 at 10:41 AM, Andrew Grieve >><agri...@chromium.org> >> > > wrote: >> > > >> > > > Here's a draft of a "how to write a blog post". I intend to add >>this >> to >> > > the >> > > > website's README.md. Wanted to get some feedback / +1 since this >>is a >> > > > "process". >> > > > >> > > > Writting a Blog Post >> > > > > -------------------- >> > > > > Blog posts live in `www/_posts`. To create a new post: >> > > > > 1. Copy one of the existing posts into a new file (changing >>the >> > name >> > > > > appropriately). >> > > > > 2. Run "rake serve" in the background. >> > > > > 3. Draft your post. >> > > > > 4. Get your post reviewed by at least one other committer >> > > > > 1. via http://reviews.apache.org. >> > > > > 2. Should be able to do this by running the "post-review" >> tool. >> > If >> > > > > the tool is not working, upload the diff manually (via "svn >>diff > >> > > file", >> > > > > and be sure to add the "cordova" group to the review request). >> > > > > 5. Update the file name to reflect the commit date (if >>necessary) >> > > > > 6. Run "rake build" >> > > > > 7. svn commit >> > > > >> > > > *Post guidelines:* >> > > > > * Use the post title as the first header. Including a header >>as >> > well >> > > > > makes the snippet on the front page look really bad. >> > > > > * Use `rake serve` and refresh frequently. Jekyll does not do >>a >> > good >> > > > job >> > > > > at telling you where errors are made. >> > > > > * Review your post yourself before asking for a review. This >> > includes >> > > > > spell-check :). >> > > > >> > > >> > >>
