On 17 January 2015 at 16:59, Ole Ersoy <ole.er...@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 <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 >> >> . >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
