Well put!! On Saturday, January 17, 2015, Gilles <gil...@harfang.homelinux.org> 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 <gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
