cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Posting Blog Posts
Date Tue, 06 Aug 2013 18:01:01 GMT
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" <tommy@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" <iclelland@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 <drkemp@google.com> wrote:
>>
>> > +1 for Michals approach
>> >
>> >
>> > On Tue, Aug 6, 2013 at 1:27 PM, Michal Mocny <mmocny@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
>><agrieve@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 :).
>> > > >
>> > >
>> >
>>


Mime
View raw message