On 01/17/2015 01:16 PM, Duncan Jones wrote:
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.
Closed questions are tagged with:
============================
Many good questions generate some degree of opinion based on expert experience,
but answers to this question will tend to be almost entirely based on opinions,
rather than facts, references, or specific expertise.
============================
So it encourages facts, references, and expertise which is good right?
For example we could ask:
What's the shortest most concise way to calculate least squares for an array of
doubles using Java 8 streams?
Also there is a `design` tag. Here's a list of questions tagged with design:
http://stackoverflow.com/questions/tagged/design
Specific example:
http://stackoverflow.com/questions/27988978/usage-of-instaceof-when-polymorphism-is-not-possible
So it seems that as long as it's kept concrete, verifiable, and targeted at
achieving a specific goal it passes.
Cheers,
Ole
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
