On 3 February 2014 10:46, Benoit Chesneau <[email protected]> wrote:
> On Mon, Feb 3, 2014 at 10:27 AM, Andy Wenk <[email protected]> wrote: > >> On 3 February 2014 10:14, Benoit Chesneau <[email protected]> wrote: >> >>> On Mon, Feb 3, 2014 at 10:03 AM, Andy Wenk <[email protected]> wrote: >>> >>>> On 3 February 2014 08:42, Benoit Chesneau <[email protected]> wrote: >>>> >>>>> On Sun, Feb 2, 2014 at 3:16 PM, Noah Slater <[email protected]>wrote: >>>>> >>>>>> Ashley, >>>>>> >>>>>> Wrt marketing plans: yes, but half way between my head, and my private >>>>>> notes. Unfortunately, my private notes also contain things from >>>>>> private conversations with people. Major mistake on my part. Apologies >>>>>> to the community. >>>>>> >>>>>> I've just sent an email giving a few people notice that I plan to >>>>>> start moving things over to the wiki. Hopefully over the next week or >>>>>> so I can get all of our existing marketing ideas in a communal space >>>>>> so we can start to discuss it. >>>>>> >>>>>> As for the marketing@ list: great. So what we'll do now is wait >>>>>> another day or two. If nobody objects, we can make the list. (This is >>>>>> how we make most of our decisions on the project. >>>>>> >>>>> >>>>> I am not sure it's a good idea to have a marketing list. Marketing >>>>> should be linked to dev and vice-versa . It's important that marketing >>>>> follows dev discussion and that dev follows and interact with the >>>>> marketing. Having 2 mailing-lists will create a disconnection. Which is >>>>> good path to the failure in tech. Also due to the low volumes of mails on >>>>> @dev this shouldn't be a problem. >>>>> >>>>> - benoit >>>>> >>>> >>>> hm ... I understand exactly what you mean and I agree, if we would >>>> speak of a company with different big departments here. But in our project >>>> I think it is totally ok that we have two different lists and the people >>>> who are strongly interested in both parts should subscribe both lists. The >>>> advantage imho is to not flood the dev@ list with unrelated stuff ... >>>> >>> >>> >>> Why do you think it would be different because we are an opensource >>> project? If marketing people don't want to follow all devs discussion then >>> there is some perspective problem imo. The same for devs that ignore the >>> users perspectives. Marketing should be elaborated with all the devs, not >>> in a side corner. At least this what we learn in management schools. And >>> this is really true for a **neutral** opensource project which has no >>> business perspective (and shouldn't have). >>> >>> - benoit >>> >> >> I did not mean to see it differently because we are an OpenSource project >> but because of the size of the project. I don't think that we will have the >> situation, that the marketing activities are going into a different >> direction because of having two lists. I still believe that everything is >> very transparent. Having more lists does not lead to in-transparencies but >> will lead in more focused discussions. The connection between marketing and >> development targets is created by the interest people have - and they >> should be interested in both and should therefor subscribe both lists ... >> if they don't they are not interested in marketing activities (what is ok >> for me). But I agree that if no dev will subscribe the marketing list, we >> will have the marketing activities in a side corner ... >> >> >> >> > this is the " if they don't they are not interested in marketing > activities" which is problematic. By marketing in a community project, I > often mean every actions taken to grow the community. I can't imagine a dev > not interested by it. Having a marketing list is also quite uncommon in an > opensource projects. But to be more concrete I often take the zeromq > project as a template to build a successful community, When you see the > mailing-lists attached to the project [1] you only have 2. If you take a > recent success in communication, the docker project, this is the same [2]. > > Imo this is part of its success. While it's totally fine to multiply the > annonces channels, I do think that a community and its members should act > together when it's about core community discussions. Part of these core > discussions are: > > - dev discussions : features/roadmap/status > - community discussions > - users discussions about some features > I can't say too much about how to create a successful community because CouchDB is just the second I actively take part. On the other hand I have quite a lot ideas how to help doing it. But I am wondering why we then have already way more than two lists. I suppose the discussion is coming up because you consider - we already have too much lists - marketing should not be included in the dev@ list (what we are actually speaking about) I can understand both points very well. But on the other hand I don't have the feeling, that having these lists is problematic. But I have subscribed to all lists and therefor do not miss anything. I don't wanna throw "he look here is my example" in the discussion. But let me just say, that the PostgreSQL project has many many lists and I guess it's working well. So my conclusion is first, that each project will find a best working way and second the success is partially related to the lists as a great part but also to many many other things. > Also lot of peopple are already subscribed to more than XXX list, to > follow N projetcs daily (customer purpose, survey...). When a project > starts to have more than 2 lists it starts to be really annoying to track > and quite expensive. > This is a fair point! I use GMail and filter all incoming list messages and give them labels. But I believe if I had 20 more, I would go crazy and miss stuff at the end. I can fully understand your concerns but on the other hand I don't think it's problematic to have a marketing list. So my suggestion is to wait for thoughts by other community members ... > > - benoit > > [1] http://zeromq.org/docs:mailing-lists > [2] http://www.docker.io/community/ > -- Andy Wenk Hamburg - Germany RockIt! http://www.couchdb-buch.de http://www.pg-praxisbuch.de GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 https://people.apache.org/keys/committer/andywenk.asc
