(FWIW, I wont stand in the way of this. I'm happy to cast a -0 vote on the website proposal.)
On 24 May 2013 10:44, Noah Slater <nsla...@apache.org> wrote: > 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, kel...@backbonetechnology.com < > kel...@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" <run...@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 <kel...@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" <nsla...@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 <kel...@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" <nsla...@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 <run...@gmail.com> wrote: >> >> >> >>> >> >>> On May 23, 2013, at 1:38 PM, Noah Slater <nsla...@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 <imusa...@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 <nsla...@apache.org> >> >>>>> Date: >> >>>>> To: marketing@cloudstack.apache.org >> >>>>> Subject: Re: Packt Book - Publish on our website? >> >>>>> >> >>>>> >> >>>>> On 23 May 2013 05:05, John Kinsella <j...@stratosec.co> wrote: >> >>>>> >> >>>>>> >> >>>>>> On May 22, 2013, at 1:30 PM, Joe Brockmeier <j...@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 <run...@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 > -- NS
