commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Mon, 07 Oct 2013 20:57:20 GMT
On 10/07/2013 08:14 PM, Benedikt Ritter wrote:
> Hi,
> since we have discussed a lot of different aspects, it may be time to sum
> things up a bit (please correct me or add things I've missed):
> Release Management - Releases take too long
> - Build is overly complex
> - dependencies to parent pom seem to be unclear
> - to few releases (more releases may attract more people)
> Technical/Coding Stuff - Commons feels legacy
> - Using old JDKs simply isn't fun
> - people are moving to alternative libs (for example guava) because commons
> feels like legacy code
> - switching to git (?!)
> Organisational Stuff - to few people work on to many components
> - Split up commons into several TLPs
> - Split up commons into bigger sub projects with individual MLs
> - decide what can be dormant and focus on core components
> Etiquette/Policies - we are a do-ocracy
> - discussions are started instead of fixing it yourself (specially in
> sandbox)
> - we don't have to be perfect (and we will never be ;-)
> - loosen API compatibility policy?
> I personally would like to at the point about commons public relations I've
> talked about a while back. Seriously: if you look at our website do you get
> the feeling that bleeding edge software is developed at commons? I intended
> to do something about the site but got caught up in the site build and then
> lost the motivation to dig deeper into the issue (which I'm a bit ashamed
> of, now that I've to spell it out loud ;-)
> The question is: how do we want to address these issues. I've seen endless
> discussions here with no result. That's another problem I see. When we get
> started with discussing, a lot of ideas come up, but little action is taken
> in the end.

I've only been lurking here for a while, so I don't have yet first hand 
experience of these problems (here), and probably a bit naive because of that.

But my experience in other ASF communities is that many of such endless 
discussions with no result can be prevented by allowing a more lazy consensus 
process, combined with more effective honoring a do-ocracy policy (those who do 

People with an itch willing to scratch it should just propose to do so.
And unless someone with a reasonable argument *and* alternative objects, be 
allowed to execute it. That should get stuff moving much faster *and* be 
motivating for others with an itch to start scratching as well.

Objecting against a reasonable proposal without being able to step in yourself 
doesn't help any project or community forward. Nor does it align with the 
'Apache way'. If you don't have the time or interest to chime in and help, step 
aside and make room for others who do.

'Community over code' really is key. For me at least that is the most important 
'thing' making the ASF so great to be part of.

Thanks, Ate
> Benedikt
> 2013/10/7 James Carman <>
>> On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <>
>> wrote:
>>> We discuss magic strings in the sandbox. Why? We don't need to discuss
>> that.
>>> Before we release we can simply check Sonar. Safe the time to discuss.
>> Fix
>>> it or leave it to Sonar to report it.
>> +1!  This sort of behavior definitely has to stop.  It frustrates our
>> contributors.  Nobody wants to get into lengthy discussions about this
>> level of minutiae.  I know some folks have given up, because they
>> don't want to have to debate every little change they make.  We vote
>> people in because they have the technical chops and have proven
>> themselves.  They don't need a babysitter!  Perhaps we should all
>> watch this video:
>> Don't get me wrong, I am glad to know that we have people so dedicated
>> to the project that they are willing to monitor every single commit
>> message that comes through (I don't have that kind of time), but
>> perhaps that time would be better spent coding.  If you see something
>> you think needs more documentation, then go document it.  If you think
>> a refactoring is in order (like introducing a constant, extract
>> method, etc.), then go do it.  Don't spend more of your time (and
>> theirs) writing up emails telling someone else to do it.  Do it
>> yourself!
>> For me, if you *have* to document your code, then you've failed.  Your
>> code should be self-documenting.  Comments eventually get out of sync
>> with the code and then you've got one big mess on your hands.  Write
>> clear, elegant code and you don't have to worry about documentation.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message