>> There is the build system for some, for some it's the people - be it
>> just for oversight. And then there is the PMC and the board reports.
>
>
> Of course, there are some _administrative_ connections; it's very
> helpful to have a home for projects that by themselves wouldn't have
> the resources to handle all the management chores.
Some call it administrative connection others like to think of it as a
community.
>> Claiming there is no relationship is a very code centric point of view
>
> Of course it is; because the fundamental, crucial, central point is
> indeed that one:
Usually the ASF is know to be more than that - at least it used to be.
> IMHO, there are no more than 5 people (at any one time the real
> count is probably closer to 2) who could claim they really oversee
> the "Commons project" as a whole as would be mandated by policy.
Interesting claim...
> It's obviously not true that all the PMC members oversee the
> whole project.
...and I am wondering what "whole project" means in this context exactly.
>> - and frankly speaking a little concerning.
>
> Why?
> Everything said and done here is related, in one way or another,
> to code.
There are committers and even PMC members at the ASF that haven't even
written a single line of code.
The ASF used to have the saying "community over code".
>> I agree - commits and jira notifications can be a lot of traffic. But
>> just the dev list on it's own is so little traffic that I am having
>> trouble understanding why we are having this discussion at all.
>
> I already mentioned that "dev" was not the main problem
So we had this whole long thread just because of a surge on the
notification/commit list? Yay!
>, although
> it is understandable, and I've said it too, that some "little"
> (programming) project's contributors might want to start benefiting
> from a home at Apache without being forced to contribute to all
> the Commons (programming) projects.
Nobody is "forced to contribute" to all components (aka "Commons
(programming) projects").
> By letting them in with limited expectations[1], the community may
> grow later on, as a side-effect.
> With oversized expectations (dictated by a policy that may not be a
> perfect to a project like "Commons"), the community scares people
> away (contrary to the many times stated goal).
What "oversized expectations" are these?
The contribution to multiple components?
That's not an expectation, merely a hope.
And we want to keep the bar low for that to happen.
It has happened - often enough.
>> Why not keep the one dev list, you unsubscribe from the commits ML and
>> keep track of issues and commits through github and jira directly?
>> Could that work?
>
>
> Maybe[2] but it is _contrary_ to the policy!
Never used github?
OK, no further questions from me then.
cheers,
Torsten
[1] And _code_ quality is the one expectation on which we can't be
flexible, because if the newcomers finally go away, it is on the
rest of us that the burden will fall.
[2] I never used "github".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
