commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Jones <dun...@wortharead.com>
Subject Re: [ALL] Too much traffic on the "dev" ML
Date Sat, 17 Jan 2015 19:16:28 GMT
On 17 January 2015 at 16:59, Ole Ersoy <ole.ersoy@gmail.com> wrote:
> GIlles,
>
> Well said as always.
>
> With respect to the goal of growing the community, I think everyone agrees
> that that's a good goal.
> So if we pick tools that developers are most likely to be used to, then they
> are more likely to join.
>
> The number of open source projects is growing everyday, and more and more
> developers are using github
> and stackoverflow facilities to get things done.  It's becoming the norm.
>
> So we developers arrive at Apache's github repository and see "Watch" turned
> off, it gives a backward appearance.
>
> Stackoverflow is great at:
> - Indexing questions
> - Providing a knowledge repository
> - Tagging and filtering content
> - Syntax highlighting content
> - Processing new questions and search previous answers
>
> This enhances the view of and intrinsic value of  the project that these
> services wrap.
> It's also a great secondary source of documentation and trails of
> experimentation.
>
> As a matter of fact I think if design discussions / questions were conducted
> on stackoverflow,
> everyone would be pleasantly surprised at the increase in sharp feedback.
> These individuals
> might subsequently join the community, because they find the design
> fascinating.

Stack Overflow is _not_ the right place to conduct design discussions
about Commons projects. Such questions would be closed, since
discussion is discouraged.

Also see this meta question, which discusses using SO as a support
forum: http://meta.stackexchange.com/q/3966/192221


>
> Cheers,
> - Ole
>
>
> On 01/17/2015 08:23 AM, Gilles wrote:
>>
>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>
>>> I agree - we're hung up on a clown from the 90s.  It's so much
>>> simpler click watch on github and get notifications.  Also
>>> stackoverflow has a much broader Java community and having traffic go
>>> through it could benefit this community.
>>
>>
>> I'm afraid that the main problem is not the tool.
>>
>> Step 1: an issue is felt as a problem by some people (from the
>>         community or might-be contributors)
>> Step 2: people (from the community) who don't feel the problem
>>         try to demonstrate that there isn't a problem, thus
>>         dismissing the (argumented) feeling of others
>>
>> This can destroy a community, or at least prevent its expansion.
>> [And the "Commons" project's (with the word "project" as in "an
>> Apache project") community certainly does not benefit from a
>> pool of contributors commensurate with its purported goal and
>> user base.]
>>
>> On the practical side, I'm not (yet) against having a single "dev"
>> list: discussions about design are usually interesting even if
>> applied to another project's codebase (with the the word "project"
>> as in "programming project").
>>
>> But lately, the flood of automatic notifications (commits and CI)
>> has drowned the useful discussions.
>> For people who do not contribute to a project (i.e. neither
>> providing code nor checking it), a commit diff is just noise
>> because they lack context (not being aquainted with the codebase).
>>
>> The Commons community's implied answer to the stated fact is
>> that people who feel that way should change their perception of
>> reality, or go away.
>>
>> The respectful answer would be to solve the problem with the
>> readily available technology of the 1990s: separate MLs for
>> each project's _notifications_ (with the word "project" as in
>> "programming project").
>>
>>
>> Regards,
>> Gilles
>>
>>> Ole
>>>
>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>
>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>> something like Google Groups where I can set my notification preferences
>>>> easily to send me updates only on certain threads such as threads I've
>>>> started, which has a nice easily browsable and searchable web interface,
>>>> and where I do not have to go through a signup process for each new
>>>> group/list I want to post to. I feel many of the problems folks are
>>>> talking
>>>> about here are caused by using a frustrating technology. E.g. it was
>>>> mentioned that if we split mailing lists that joining every list would
>>>> be
>>>> very painful. Perhaps that's because the process of joining just a
>>>> single
>>>> list is too difficult. Having to setup filters is also not very
>>>> user-friendly. How do I make a filter that says only put threads on
>>>> which
>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>> obvious as clicking a single button. And even with filters I still don't
>>>> want most of this garbage coming to my mail account anyway because it
>>>> pollutes my search results when I'm looking for something I do care
>>>> about.
>>>> I signed up for the dev list just so that I could ask that someone
>>>> reviews
>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>> (which
>>>> I still need help with), but I really have no interest in getting any
>>>> commons mail beyond that. I've never participated in any of these other
>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>> cause
>>>> me to start. The web interface for mailing list archives is truly
>>>> horrendous.
>>>>
>>>>
>>>>
>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gilles@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>
>>>>>> Was it mentioned that anybody would be forbidden to subscribe to
any
>>>>>>>
>>>>>>> ML they see fit?
>>>>>>>
>>>>>> You missed my point - but never mind.
>>>>>>
>>>>> What was it?
>>>>>
>>>>> Judging from your comments below, you completely missed mine.
>>>>>
>>>>>
>>>>>
>>>>>>   That comparison is pretty flawed as those projects are not tiny
>>>>>>>>
>>>>>>>> components.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not talking about the size of components, but the size of
the
>>>>>>> ML traffic.
>>>>>>>
>>>>>> So just because a component/project has a lot of ML traffic you want
>>>>>> to make it TLP?
>>>>>>
>>>>> I never said that.
>>>>> I'm only complaining about ML traffic.
>>>>>
>>>>>   Usually it should be about having enough active committers and users.
>>>>>>
>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>> mean the same.
>>>>>>
>>>>>>
>>>>>>   I've never a great fan of umbrellas but the components are so small
>>>>>> -
>>>>>>>>
>>>>>>>> I don't see another option. The thought of components to
go TLP
>>>>>>>> feels
>>>>>>>> just plain silly to me. Hence it would be great to work together
as
>>>>>>>> a
>>>>>>>> community that takes care of those components.
>>>>>>>>
>>>>>>>
>>>>>>> The idea of "Commons Math" being a component is silly, but we
can
>>>>>>> accept
>>>>>>> silly things that result from history (and consider the practical
>>>>>>> advantages, as I noted elsewhere).
>>>>>>>
>>>>>> Well, by the current definition it's not an Apache project. Call
it
>>>>>> sub-project if you like - I don't care.
>>>>>>
>>>>> What I'm calling "project" is a _programming_ project; that's the word
>>>>> I'm used to; do you have another one?
>>>>> Every component is a separate programming project, it's a simple fact.
>>>>>
>>>>>   At some stage we decided to call it component. After all I see it as
>>>>>>
>>>>>> a library.
>>>>>>
>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>> blown project like hadoop or httpd?
>>>>>> Not sure it Math holds that comparison but you are welcome to convince
>>>>>> us.
>>>>>>
>>>>> I think that this has nothing to do with this thread.
>>>>>
>>>>>
>>>>>>   If it depends on the name of the list, I guess that the "sense
of
>>>>>>>
>>>>>>> community" is not very developed...
>>>>>>>
>>>>>> And that's what I call an oversimplification.
>>>>>>
>>>>>>
>>>>> You brought that up (one community == one list). Or another missed
>>>>> point?
>>>>>
>>>>>
>>>>> Gilles
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> .
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message