fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Walch <mwa...@apache.org>
Subject Re: [DISCUSS] User mailing list for Fluo
Date Tue, 19 Dec 2017 23:13:02 GMT
I am OK with only having one mailing list for Fluo discussion but it
shouldn't be called 'dev'. If we have a 'dev' list, we should also have a
'user' list so we don't confuse users.  If we want just one list, it should
be named something like 'general'.

There is a 'Contact Us' page on our website that provides a lot of
documentation for interacting with the community.

https://fluo.apache.org/contactus/

However, it could be more visible on the main page.  It's buried under the
'Community' tab. We could put add a 'Contact Us' or 'Contact' link in the
navbar to make it more visible.

On Tue, Dec 19, 2017 at 5:38 PM Josh Elser <elserj@apache.org> wrote:

> Yeah, I'd agree with Christopher. It seems like the real problem is that
> there is lacking documentation for how users should interact with the
> community, less of a "not enough mailing lists" :)
>
> On 12/19/17 12:34 PM, Christopher wrote:
> > I think the main reason for a separate list is to keep some organization
> of
> > high traffic lists. Another reason is separation of concerns (users don't
> > necessarily care about dev concerns). The former doesn't really apply
> > because we're so low traffic, but the latter might. I'm +0.
> >
> > On Tue, Dec 19, 2017, 11:54 Keith Turner <keith@deenlo.com> wrote:
> >
> >> I am in favor.  A user list would follow the pattern of many other
> >> projects making it easier on someone new to contact us.
> >>
> >> On Tue, Dec 19, 2017 at 11:40 AM, Mike Walch <mwalch@apache.org> wrote:
> >>> When Fluo started incubation, a user mail listing wasn't created to
> limit
> >>> the number of mailing lists.  However, I think we are due for one. Does
> >>> anyone have any views on one being created?  If there are no
> objections,
> >> I
> >>> will create a user mailing list this week.
> >>
> >
>

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