cloudstack-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Packt Book - Publish on our website?
Date Fri, 24 May 2013 09:44:41 GMT
Kelcey, I think that's a false dichotomy. This isn't about marketing /
coder perspectives. :)

We have two options, as I understand it:

1) Create a page on our official website and list "recommended" or
"approved" books. This will almost certainly give the impression (rightly
or wrongly) that these books have been reviewed and are endorsed by the
project. Doing this will allow us to filter the books, and make sure only
the best resources are being promoted. But it also introduces an approval
process and review bottle-neck, as well as potentially shutting out some
members of the community, opening up to accusations of in-group
favouritism[1]. (In fact, this has already raised its head in the form of
"let's only accept books written by committers".)

2) Create a page on our wiki, and link to it from our website (prominently,
if need be). Because this is community editable (i.e. not behind a commit
bit wall) it should be obvious that this is a community resource, and
hence, caveat emptor. Our approval system is reduced to lazy consensus
(i.e. we monitor the wiki changes and revert anything we don't like). The
wiki might not look as good as the site, but if we promote it heavily from
the site, there shouldn't be too much difference.

[1] http://en.wikipedia.org/wiki/In-group_favoritism


On 24 May 2013 10:23, kelcey@backbonetechnology.com <
kelcey@backbonetechnology.com> wrote:

> Sebastien,
>
> I completely agree, and that's why many on the marketing channel often
> have friction with core developers. The corporate side of me says plaster
> it everywhere, free advertisement, co-op marketing efforts, put CloudStack
> in everyones hands...
>
> But I have tried over the last year to learn why this and other OSS
> communities don't like to operate in that way.
>
> I now have a moral dilemma... Should I try and work with others to bend
> the community into a more sales/product ecosystem driven approach, or
> temper myself to the dev-centric code-first OSS neutrality mentality.
>
> I honestly am starting to feel that is this were a vote I would vote +0,
> even though I put months of my time into this book, lol.
>
> I am going to shift my position back to observation on this thread.
>
> Sent from my HTC
>
> ----- Reply message -----
> From: "Sebastien Goasguen" <runseb@gmail.com>
> To: <marketing@cloudstack.apache.org>
> Subject: Packt Book - Publish on our website?
> Date: Fri, May 24, 2013 1:20 AM
>
> On May 23, 2013, at 2:28 PM, Kelcey Jamison Damage <kelcey@bbits.ca>
> wrote:
>
> > Fair enough, I was hoping to get a sense for those that are opposed to
> the summary, and the reason why.
> >
> > ----- Original Message -----
> > From: "Noah Slater" <nslater@apache.org>
> > To: marketing@cloudstack.apache.org
> > Sent: Thursday, May 23, 2013 11:27:39 AM
> > Subject: Re: Packt Book - Publish on our website?
> >
> > I don't think we have consensus on this.
> >
> >
> > On 23 May 2013 19:25, Kelcey Jamison Damage <kelcey@bbits.ca> wrote:
> >
> >> Ok,
> >>
> >> To summarize it looks like we all want to have 3rd party resources
> >> available, we want to ensure the content of those resources reflects
> >> properly on the project, and the wiki sounds like the best way to do it
> and
> >> stay neutral.
> >>
> >> Does every one agree with this so far?
> >>
>
> I don't think the wiki is the best place. It's a great thing to have books
> about CloudStack and we should feature them prominently.
> We could mention on the website something like: "Listing these books does
> not mean that the Apache project endorses them"
>
> FWIW, I feel the same about the case studies, the wiki is not the best
> place for them.
>
> However, if you all feel the wiki is the best place, I won't fight it.
>
> -Sebastien
>
>
> >> Thanks
> >>
> >> ----- Original Message -----
> >> From: "Noah Slater" <nslater@apache.org>
> >> To: marketing@cloudstack.apache.org
> >> Sent: Thursday, May 23, 2013 11:21:31 AM
> >> Subject: Re: Packt Book - Publish on our website?
> >>
> >> If things are done on the wiki, it would be clear that this is a
> community
> >> resource, and not an official project recommendation. We always have the
> >> option of removing something that is obviously spammy, or low-quality,
> etc.
> >>
> >>
> >> On 23 May 2013 18:48, Sebastien Goasguen <runseb@gmail.com> wrote:
> >>
> >>>
> >>> On May 23, 2013, at 1:38 PM, Noah Slater <nslater@apache.org> wrote:
> >>>
> >>>> Book review is very costly. Several days, to weeks, depending how
> >>> thorough
> >>>> you are, and how much free time you have, etc. Do we really want to
> >>>> introduce this sort of bottleneck?
> >>>
> >>> When I commented earlier I was not thinking of putting any hard
> barriers
> >>> like committer status.
> >>>
> >>> I was merely thinking about books that can be written in couple days,
> >> with
> >>> very poor english, terrible formatting and that could be out of scope
> >>> despite a "cloudstack" title. We don't want those books listed
> anywhere.
> >>>
> >>> A blanket approval for listing books is not a good idea, we need a
> >> minimal
> >>> sanity check.
> >>>
> >>> -sebastien
> >>>
> >>>>
> >>>>
> >>>> On 23 May 2013 16:27, Musayev, Ilya <imusayev@webmd.net> wrote:
> >>>>
> >>>>> Perhaps we can revisit the thought of  making it commiter written
VS
> >>>>> comitters reviewed.
> >>>>>
> >>>>> As error safeguard measure it would make sense if have at least
3
> >>>>> commiters review the publication.
> >>>>>
> >>>>> Reason being, while many of us are comitters, some of us maybe more
> >>>>> competent in some areas of ACS and less on the other. Therefore
if we
> >>> have
> >>>>> several comitters review the publication, we minimize the error
> >>> posibilty.
> >>>>> if i was to make an example, i've spent alot of time building private
> >>>>> clouds that would suit traditional enterprises, i may not be an
> expert
> >>> on
> >>>>> designing web hosting shops (just yet).
> >>>>>
> >>>>> Obviously exclusions apply, if someone have spent many years as
a
> core
> >>> ACS
> >>>>> architect and developer - he may not need several commiters to review
> >>> the
> >>>>> publication -  though it would not hurt.
> >>>>>
> >>>>> The commiters who will be reviewing publication must notify the
> >>> community
> >>>>> via mailing list. If there are points of uncertainty,  the should
be
> >>>>> brought on ML as well.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -------- Original message --------
> >>>>> From: Noah Slater <nslater@apache.org>
> >>>>> Date:
> >>>>> To: marketing@cloudstack.apache.org
> >>>>> Subject: Re: Packt Book - Publish on our website?
> >>>>>
> >>>>>
> >>>>> On 23 May 2013 05:05, John Kinsella <jlk@stratosec.co> wrote:
> >>>>>
> >>>>>>
> >>>>>> On May 22, 2013, at 1:30 PM, Joe Brockmeier <jzb@zonker.net>
wrote:
> >>>>>>> Books authored by committers might be a good metric.
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>
> >>>>> I think this is exclusionary. As Kelcey points out, there's a high
> >>>>> probability that some of the best books on CloudStack are not written
> >> by
> >>>>> committers.
> >>>>>
> >>>>>
> >>>>> On 23 May 2013 07:06, Sebastien Goasguen <runseb@gmail.com>
wrote:
> >>>>>
> >>>>>>
> >>>>>> Let me put it bluntly. IMHO wiki pages are a death sentence,
nobody
> >>> will
> >>>>>> find that information.
> >>>>>> If it's not featured on the website then there is no point talking
> >>> about
> >>>>>> it.
> >>>>>
> >>>>>
> >>>>> Blunt, but hyperbolic. ;) If you really feel so strongly about the
> >> wiki,
> >>>>> you should propose that we shut it down. ;)
> >>>>>
> >>>>> The wiki is a community resource, and we should embrace that, and
> >>> encourage
> >>>>> that.
> >>>>>
> >>>>> If you're concerned that people visiting the main website will not
> >>> notice,
> >>>>> and will never find, a page that lists third-party resources, then
I
> >>>>> suggest a patch that provides a link in the nav saying "third-party
> >>>>> resources" and link it to the wiki.
> >>>>>
> >>>>> --
> >>>>> NS
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> NS
> >>>
> >>>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message