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" <[email protected]> To: <[email protected]> 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 <[email protected]> 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" <[email protected]> > To: [email protected] > 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 <[email protected]> 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" <[email protected]> >> To: [email protected] >> 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 <[email protected]> wrote: >> >>> >>> On May 23, 2013, at 1:38 PM, Noah Slater <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> Date: >>>>> To: [email protected] >>>>> Subject: Re: Packt Book - Publish on our website? >>>>> >>>>> >>>>> On 23 May 2013 05:05, John Kinsella <[email protected]> wrote: >>>>> >>>>>> >>>>>> On May 22, 2013, at 1:30 PM, Joe Brockmeier <[email protected]> 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 <[email protected]> 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
