Re: ALC, and who can speak on behalf of Apache

[Alex Harui]

I've only been partially following, and I hear and respect the desire for 
"quality control", but IMO, people talk about Apache all of the time in other 
events.  For example, when Flex joined the incubator in January 2012, there was 
a Flex user conference shortly after in April 2012.  I spoke there about the 
transition from Adobe to Apache and laid out what I knew about Apache at the 
time.  I posted slides beforehand, but I'm not sure our Mentors looked them 
over carefully.  We were a podling, so no official PMC members and no Mentors 
were in attendance.  IIRC, I also practiced this presentation at a small Meetup 
before the conference.  I'll bet this happens at lots of conferences for 
podlings.  I included a disclaimer that I wasn't speaking on behalf of Apache, 
just passing on what I've learned so far.

Hence, my gentle suggestions that disclaiming is better than too much oversight 
on these community meetings, otherwise ALC is going to be under a heavier 
burden than other community outreach.  If that's because you want to make ALC 
the official way to learn about Apache, roughly as formal as the Incubator, ok, 
then fine, but that might cause other volunteers to shy away or find a path of 
less overhead by skipping the ALC title and buying a case of beer instead.

My 2 cents,
-Alex

On 12/12/19, 2:10 PM, "Craig Russell"  wrote:

Hi Swapnil,

I realize I'm coming late to this discussion but would like to offer a 
small bit of feedback.

Like others, I think we need to try to get qualified people running local 
groups. One Member plus two PMC members gives us three, which is a magic number 
for decision-making here. Even if they don't attend all meetings, it's at least 
some oversight from folks who have earned merit.

Random talks that present how we do things here, by people we don't know, 
makes me nervous. We might consider requiring presentations to be posted 
publicly some time (one week?) before the meeting which would allow for at 
least some oversight. 

And there are plenty of such presentations publicly available and some can 
be edited to suit (e.g. see the Training podling for examples of presentations 
on The Apache Way).

I endorse the concept and look forward to a proposal.

Craig

> On Dec 11, 2019, at 11:59 AM, Swapnil M Mane  
wrote:
> 
> Thank you so much, everyone, for your kind and valuable inputs.
> As a next step, we will work on drafting the ALC proposal to the board.
> 
> 
> - Best regards,
> Swapnil M Mane,
> 
https://nam04.safelinks.protection.outlook.com/?url=www.apache.orgdata=02%7C01%7Caharui%40adobe.com%7C3ac2d86ccbf54019b11c08d77f500aba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637117854065911699sdata=NQimXPkKRHJo%2FpQ9yYjcnqVPJuVHumRLi6GYPVyQICE%3Dreserved=0
> 
> On Thu, Dec 12, 2019 at 12:20 AM Rich Bowen  wrote:
>> 
>> 
>> 
>> On 12/6/19 4:42 PM, Roman Shaposhnik wrote:
>>> One potential (if not solution -- but at least a line of thought) could 
be
>>> to bring these efforts into the fold officially by requiring them to be
>>> official sub-projects of ComDev PMC. Then we can have a policy requiring
>>> a certain governance oversight over those sub-projects (like requiring
>>> a certain # of PMC/members, etc.).
>> 
>> This just feels like too much structure/bureaucracy to me. We want just
>> enough oversight, but we don't want to kill it with too much, either.
>> 
>> If, at some later date, this grows to the point where it seems to *need*
>> this much oversight, then, great, we take that step then.
>> 
>> Small, reversible steps.
>> 
>> --
>> Rich Bowen - rbo...@rcbowen.com
>> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frcbowen.com%2Fdata=02%7C01%7Caharui%40adobe.com%7C3ac2d86ccbf54019b11c08d77f500aba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637117854065911699sdata=vfHus%2BNTsFNCnmwIRFIJunUQ0Qoxv%2BsHBJb5Dsq74EY%3Dreserved=0
>> @rbowen
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: ALC, and who can speak on behalf of Apache

[Alex Harui]

And that's why I suggested required disclaimers.  Big events have disclaimers.  
That way, Apache is not endorsing their message as 100% accurate on behalf of 
the foundation, just their attempt to get the message out.  Sounds like Rich 
will make sure there is some ASF-experienced people involved, but I'm pretty 
sure there are ASF members who would say things that need correcting, so unless 
Rich can certify an ASF Members knowledge, it just lowers the risk by some 
amount and doesn't bring it to zero.

So yeah, try to get as many experienced ASF people involved in the messaging 
from each ALC, to lower risk.  Add a disclaimer to disengage responsibility for 
errors.  Execute error recovery when needed.

My 2 cents,
-Alex

On 12/6/19, 9:19 AM, "Austin Bennett"  wrote:

The bits on mentorship make some sense, although I am confused.  If about
who is allowed/endorsed to speak on behalf of the ASF, then:

* Should only speakers at events be of a condoned status (how are they
vetted)?
or:
* Would a required minimum number of mentors (PMC/Foundation members) be
required in attendance, to be able to correct mis-messages?
or more extreme:
* Should every piece of content be recorded and reviewed, and if
insufficient then the group should be discredited (that is extreme and
unlikely, but I think you see the example).

^ The first two perhaps are things that should then also be included in the
report of an event.

Otherwise, it seems without the above invites much more bureaucracy without
actually doing much to solve/prevent the problem that seems to concern
people?






On Fri, Dec 6, 2019 at 8:37 AM Rich Bowen  wrote:

>
>
> On 12/4/19 5:56 PM, Issac Goldstand wrote:
> >
> > On Dec 4, 2019 22:15, Rich Bowen  wrote:
> >
> >
> > . But I've learned from Fedora user
> > groups that allowing any random stranger to start up a group, using
> our
> > Trademarks, to promote whatever message comes into their head, is
> > *going* to bite us in the butt, sooner rather than later.
> >
> > Are these from groups that are managed/overseen by RedHat? Can you share
> > more information about what you've learned the hard way? Because maybe
> > the way I suggest below is objectively wrong, and if so I'd rather
> > understand the faulty reasoning on my part sooner, rather than later...
>
> I'm reluctant to tell stories on a public list, particularly when almost
> all of the stories are third-hand. But the lesson learned is that when
> you give someone a title, there's a chance that they will take it as a
> fiefdom - a little kingdom where they rule, call the shots, and don't
> have to answer to anyone else.
>
> >
> > I've mentioned before that my standpoint is that it's impossible to
> > properly police every fan driven event out there, and I seem to recall
> > that use of a trademark by fans in a manner that isn't making profits is
> > generally considered acceptable use.  Is it not therefore a good-enoungh
> > way to start by allowing (CTR instead of RTC as it were)?
>
> Absolutely. We don't even *want* to police every fan event. And we want
> a LOT of fan events. The nuance is the moment we give our Official Seal
> Of Approval to a group/event/organization, then we are implicitly
> approving their message, and that's where we introduce audience confusion.
>
> >
> >
> > This is *NOT* about the Indore group and their recent event. Rather
> > it's
> > about the future. The groups currently out there are full of
> > experienced
> > Apache people. All well and good. The second wave will be full of
> > people
> > wanting to promote their business, or their personal brand, using 
our
> > name, and spreading misinformation about Apache under our official
> > banner.
> >
> > Once there is enough traction in the user groups that we can see a clear
> > difference between user (fan) groups that are promoting Apache vs groups
> > that are using the name to promote themselves, we could go with the
> > carrot and stick. The carrot is recognition and support by the ASF for
> > the good players, and the stick is trademark abuse complaints and
> > threats of legal action to those that don't.
> >
> > Or even just the stick.
> >
> > Because the carrot means having to make rules. And rules make life
> > harder for volunteers. Pulling off a successful meetup/event and
> > maintaining a successful community is hard enough without rules.
> > Sometimes rules are unavoidable, and so be it, but let's keep the
> > barrier of entry as low as possible for the amazing folks who are trying
> > to raise positive awareness of what we do here.
> >
> 

Re: ALC, and who can speak on behalf of Apache

[Alex Harui]

From the peanut gallery:  IMO, without a formal training/certification program, 
what even an ASF Member understands about the Apache Way, not to mention 
committers who are not members, is up for grabs.  It is essentially the party 
game "telephone" where one person says something to another person who tries to 
pass it on.

Also, it is humans speaking and humans listening, so misspeaking and 
misunderstanding is guaranteed.

Seems like a better approach is along the lines of what the Events page Shane 
linked to contains.  It contains a disclaimer for events.  I thought we were 
supposed to also include a disclaimer in slide decks, but I couldn't find a 
reference to that.

IOW, if you require a disclaimer that people speaking about Apache are just 
enthusiastic volunteers and not official spokespeople, and have them state how 
long they've been with involved at Apache as contributor/committer/member, then 
these community groups are the same as anyone else talking about the good 
things at Apache at some potluck dinner with friends.  It doesn't have to be 
100% accurate, it just has to get the word out in a reasonable fashion.

And then you will get good at fixing common misunderstandings and create a FAQ 
of common misunderstandings to guide future presentations.  "Oh, well that 
person is relatively new to the ASF and didn't quite grok that yet.   The real 
story is"

IMO, better to plan for error recovery than to attempt perfection in the 
message.

-Alex

On 12/5/19, 7:53 AM, "Jim Jagielski"  wrote:



> On Dec 5, 2019, at 3:52 AM, Mark Thomas  wrote:
> 
> Picking up on one point
> 
> On 05/12/2019 05:31, Swapnil M Mane wrote:
> 
>> -- To form an ALC, there should be at least 2 committers or 1 ASF member.
> 
> I don't agree with this. I don't think this is acceptable. The bar for
> committership is too low to be used as a test for "Understands the
> Apache Way".

Maybe 2 PMC members...?

Re: Introducing lists based on the overall project categories?

[Alex Harui]

Hi Bertrand,

Your link took me to a post about splitting lists because some list is busy, 
but AIUI, this proposal for iot@ is to communicate between related projects.  
Does the ASF have an example of a cross-project list that failed?

Thanks,
-Alex

On 6/7/19, 4:34 AM, "Bertrand Delacretaz"  wrote:

On Fri, Jun 7, 2019 at 12:48 PM Christofer Dutz
 wrote:
> ...For me it looks as if tech@ would be one huge list ...

It *might* eventually become large, then big, then huge...but like
everything it will start small.

If it does indeed grow, it *might* be fine to farm out specific busy
topics to their own lists.

Until then, a single list is the best way to create momentum around a
place to have cross-cutting technical discussions at the ASF.

I think I've exposed my position, multiple times so I'll stop now and
as mentioned whoever does the work decides.

Please just keep the Wisdom Of The
Elders in mind, as reported at

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrep.codeconsult.ch%2F2011%2F12%2F06%2Fstefanos-mazzocchis-busy-list-pattern%2Fdata=02%7C01%7Caharui%40adobe.com%7Cd4a971a7b8914177060c08d6eb3c0d32%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636955040515183248sdata=dHSIBSpDbUNxaXn2mFx1DfznQfYvEgLpMWXMq8OsrOQ%3Dreserved=0
(blog post of mine based on content provided by Stefano Mazzocchi’s,
Apache Cocoon's original author)

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Discuss] Attributing contributions to commercial vendors investing in projects

[Alex Harui]

I’m sorry, I do not understand these responses.   I did not mention 
advertising, only attribution.   I did not mention paying to get listed in the 
NOTICE.   These negative assumptions discourage my motivation to contribute to 
these kinds of discussions.  

It is my understanding that the employer of a committer almost always holds 
copyright of the code contributed by that committer.  I do not see anything in 
the linked license that prohibits anyone from adding their copyright to NOTICE 
because I thought a copyright was a legal notice.  And plenty of companies that 
donated the original code are already in NOTICE files.

Please educate me.

Thanks,
-Alex

On 4/19/19, 6:15 AM, "Sam Ruby"  wrote:

On Fri, Apr 19, 2019 at 8:03 AM Jim Jagielski  wrote:
>
> > On Apr 19, 2019, at 1:06 AM, Alex Harui mailto:aha...@adobe.com.INVALID>> wrote:
> >
> > Lots of NOTICE files give attribution to the pre-Apache project owner.  
Why not let other companies add their logo to NOTICE if it is important to them?
>
> NOTICE has a specific reason for existence as the place where such 
notices and information that MUST be delivered to the end-user is placed. It's 
not designed as a catch-all for any "advertising" that someone would like 
people to see :)

Just adding a citation to back up Jim's point.  See section 4d of the
Apache License:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flicenses%2FLICENSE-2.0data=02%7C01%7Caharui%40adobe.com%7C7cb64661c0db4c500f4008d6c4c90dcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636912765171411465sdata=uJR2ccKwN3JWGJpcC%2Fxq7jNVWy9EernG%2BV9GCWJoCVc%3Dreserved=0

- Sam Ruby

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Discuss] Attributing contributions to commercial vendors investing in projects

[Alex Harui]

From the peanut gallery:

IMO, big corporations have enough money to get their names out there and 
influence projects if they want to.  So, it might be the best use of time to 
find ways to limit the impact on the projects instead of trying to prevent them 
from using their names.  The ASF tends to like transparency, so hiding 
corporate affiliation seems wrong.

The part-time volunteer is always going to have an uphill battle against 
influencing a project against a bunch of full-time paid committers whether you 
know their employers or not.  The full timers will be able to influence the 
project.

Isn't the real key to independence from corporations things like:
1) your committer rights move from job to job with you.
2) a commit should not be rejected based on business priorities, only technical.
Are there more?

Branding could dictate some policy to prevent a NASCAR uniform look to the 
project's landing page, but since corporations are effectively contributing 
significant money to the ASF by paying folks to commit code, why shouldn't they 
deserve recognition?  Could projects have their own Thanks page?

Lots of NOTICE files give attribution to the pre-Apache project owner.  Why not 
let other companies add their logo to NOTICE if it is important to them?

Maybe allow these two things and see if that makes the corporations happy.

Thanks,
-Alex

On 4/18/19, 4:06 PM, "Mark Thomas"  wrote:

This is a tricky one.

If everything is working as it should, corporate affiliation is irrelevant.

However, employment is a factor in a number of different ways a project
can start to head in the wrong direction. For example, employees of a
company always giving priority to reviewing and committing the work of
colleagues to the disadvantage - and discouragement - of other
contributors/committers.

This sort of thing can be very hard to spot from the mailing list unless
you are closely following a project over an extended period of time.
Something that those providing oversight - the directors - do not have
the bandwidth to do for all 200+ projects. Even if an issue is raised by
someone familiar with the project it remains hard to spot for any
external person trying to review the situation.

It would be a lot easier to pick up on behaviours like the one I
described above if corporate affiliation was readily available. However,
making that information readily available has many downsides which have
been articulated by others in this thread already.

If feels a bit catch-22. If all is well, we don't need it. Having it
makes it easier to spot when things go wrong but also increases the
chances of things going wrong.

I don't have a solution to this. Possible options include:
a) adding current employer(s) to the private information we hold for
   each committer so it is available to look up if there are concerns
b) asking for current employer(s) as part of investigating a concern
   raised with the way a project was operating
c) leaving things as they are on the basis that the risk of harm exceeds
   the benefit (I think it does for a and b)

Mark




On 18/04/2019 15:40, Jim Jagielski wrote:
> Yes. Corporate affiliation is really immaterial, and should be. Another 
reason for this is that one's job may, and often does, change. Who you are, and 
what you do, and how you provide "value" to a project, should not and does not. 
To associate one's merit with one's employment means that every time one 
changes jobs, it would/could have a major disastrous side-affect on one's place 
in the project. For example, if the only reason why Zap Foobarski has merit was 
because she was employed by Oracle, for example, and she was no longer employed 
there, then it places an undue and unfair disadvantage on her and unfair 
advantages on others. It is all about personal self-involved, self-motivated 
interest. If that is supported or enhanced by one's employer, that is great. 
But it is not a determining factor.
> 
>> On Apr 17, 2019, at 9:49 PM, Phil Steitz mailto:phil.ste...@gmail.com>> wrote:
>>
>>
>>
>> On 4/17/19 6:05 PM, Sam Ruby wrote:
>>> On Wed, Apr 17, 2019 at 6:04 PM Joan Touzet mailto:jo...@apache.org>> wrote:
 I'm generally in agreement with Rich, Jim, Shane, Sam and the other
 "grey beards" who have responded on this thread already. We recognize
 the individual, not the company, and the individual gets the merit.
>>> Meta comment: looking at the "grey beard" comments (including my own),
>>> I'm not impressed with how we collectively communicated (though Rich
>>> comes closest).
>>>
>>> This was a perfect opportunity to practice 

Re: on "meritocracy"

[Alex Harui]

On 3/22/19, 12:04 AM, "Roman Shaposhnik"  wrote:

It would be very important to come up with a replacement that is
as effective as what we're trying to replace. Frankly, I don't know
a single candidate.

Does anyone?

Do-ocracy - I think we've used this word before to describe the ASF.  Seems to 
have definitions in the Urban Dictionary.
Action-ocracy - This might be a new word and thus we can define it to be what 
we want it to be.

HTH,
-Alex

Re: Why are large code drops damaging to a community?

[Alex Harui]

This is just a nitpick, but it is the subject line that is bothering me.  
Having a "no large code drops" mantra is not the same as a "limit off-list 
collaboration" mantra which is different from a "no off-list development" 
mantra.

For Flex, Adobe made something like 5 large code drops.  It simply took so long 
to clear the various chunks of code being donated to Apache through Adobe's 
approval process that it was done in stages.  In fact, if I had time, the 
Flex/Royale community wanted it, and I could get Adobe to support it, I'd 
bestow a couple of other large code drops to Apache.  It is all pre-existing 
code, but again, the subject line makes it sound like any large code drop is 
bad, which is not true.

To say "no off-list development" could be construed as some limit on how many 
lines of code you can write as an individual before making it available to 
others to review.

I think the real key here is "off-list collaboration".  There will always be 
off-list collaboration, and I'll bet some really significant things can happen 
at a hackathon.  That should not be prohibited.  I think you are simply trying 
to express the notion that groups, especially groups defined by having a common 
employer, don't do too much collaboration off-list before inviting others into 
the conversation.

My 2 cents,
-Alex

On 10/24/18, 7:17 AM, "Myrle Krantz"  wrote:

Hey all,

I'd like to invite anyone with relevant positive or negative
experiences with off-list development or large code drops to share
those experiences.  The ASF policy of "no off-list development" is
implemented in a wide variety of ways in various communities, but
there are still may be some things that we can agree are absolute
no-goes.  I'd like to figure out what things we see as:

* You might get away with that once, but don't try it twice.  That's
damaging to the community.
* Avoid doing that unless you have a really good reason that the
community has accepted.
* That has a bit of a smell to it.  Have you discussed that with your 
community?
* That's fine.  You're helping your community.
* What a wonderful idea! Absolutely do that if you and your community want 
to!

I'm hoping to put together a diagnostic tool for offlist development
that can help communities help themselves.  Something similar to
Beck's Depression Inventory.  Because like mental health, community
health is complex, and sometimes it is not clearly 'good' or 'bad'.

In order to do that though, I'd like to read your stories.  Especially
from the people who've been around a few projects and seen a few
things.  The stories Malcolm, Chris, and Jim already shared are
exactly the sort of thing I'm looking for, so if y'all would like to
elaborate that'd be really cool too.

Best Regards,
Myrle

On Sat, Oct 20, 2018 at 6:41 AM Myrle Krantz  wrote:
>
> Hey Jim,
>
> I’d say they are a symptom *and* a problem. But putting that aside, can 
you unroll what you mean please?
>
> What was that code drop from SGI a symptom of?
>
> What did Robert Thau do (or not do), before during or after to ensure the 
success of httpd?
>
> Best Regards,
> Myrle
>
> On Sat 20. Oct 2018 at 00:28 Jim Jagielski  wrote:
>>
>> I would say that, in general, large code drops are more a *symptom* of a 
problem, rather than a problem, in and of itself...
>>
>> > On Oct 19, 2018, at 5:12 PM, Alex Harui  
wrote:
>> >
>> > IMO, the issue isn't about large code drops.  Some will be ok.
>> >
>> > The issue is about significant collaboration off-list about anything, 
not just code.
>> >
>> > My 2 cents,
>> > -Alex
>> >
>> > On 10/19/18, 1:32 PM, "James Dailey"  wrote:
>> >
>> >+1 on this civil discourse.
>> >
>> >I would like to offer that sometimes large code drops are 
unavoidable and
>> >necessary.  Jim's explanation of httpd contribution of type 1 is a 
good
>> >example.
>> >
>> >I think we would find that many projects started with a large code 
drop
>> >(maybe more than one) - a sufficient amount of code - to get a 
project
>> >started.  When projects are young it would be normal and expected 
for this
>> >to happen. It quickly gets a community to a "thing" that can be 
added to.
>> >
>> >It obviously depends on the kinds of components, tools, frameworks, 
etc
>> >that are being developed. Game theory is quite apropos - 

Re: Why are large code drops damaging to a community?

[Alex Harui]

IMO, the issue isn't about large code drops.  Some will be ok.

The issue is about significant collaboration off-list about anything, not just 
code.

My 2 cents,
-Alex

On 10/19/18, 1:32 PM, "James Dailey"  wrote:

+1 on this civil discourse.

I would like to offer that sometimes large code drops are unavoidable and
necessary.  Jim's explanation of httpd contribution of type 1 is a good
example.

I think we would find that many projects started with a large code drop
(maybe more than one) - a sufficient amount of code - to get a project
started.  When projects are young it would be normal and expected for this
to happen. It quickly gets a community to a "thing" that can be added to.

It obviously depends on the kinds of components, tools, frameworks, etc
that are being developed. Game theory is quite apropos - you need a
sufficient incentive for *timely* collaboration, of hanging together.

Further, if your "thing" is going to be used directly in market (i.e. with
very little of a product wrapper ), then there is a strong *disincentive*
to share back the latest and greatest. The further from market immediacy
the easier it is to contribute. Both the Collaboration space and
Competitive space are clearly delineated, whereas in a close to market
immediacy situation you have too much overlap and therefore a built in
delay of code contribution to preserve market competitiveness.

So, combining the "sufficient code to attract contribution" metric with the
market-immediacy metric and you can predict engagement by outside vendors
(or their contributors) in a project. In such a situation, it is better, in
my view, to accept any and all branched code even if it is dev'd off-list.
This allows for inspection/ code examination and further exploration - at a
minimum.  Accepting on a branch is neither the same as accepting for
release, nor merging to master branch.

Now, the assumption that the code is better than what the community has
developed has to be challenged.  It could be that the branched code should
be judged only on the merits of the code (is it better and more complete),
or it could be judged on the basis that it "breaks the current build".
There can be a culture of a project to accept such code drops with the
caveat that if the merges cannot be done by the submitting group, then the
project will have a resistance to such submissions (you break it, you fix
it), or alternatively that there will be a small group of people that are
sourced from such delayed-contribution types - that work on doing the
merges.  The key seems to be to create the incentive to share code before
others do, to avoid being the one that breaks the build.

~jdailey67




On Fri, Oct 19, 2018 at 6:10 AM Jim Jagielski  wrote:

> Large code drops are almost always damaging, since inherent in that
> process is the concept of "throwing the code over a wall". But sometimes 
it
> does work out, assuming that continuity and "good intentions" are 
followed.
>
> To show this, join me in the Wayback Machine as Sherman and I travel to
> the year 1995...
>
> This is right around the start of Apache, back when Apache meant the web
> server, and at the time, the project was basically what was left of the
> NCSA web server plus some patches and bug fixes... Around this time, one 
of
> the core group, Robert Thau, started independent work on a re-architecture
> of the server, which he code-named "Shambala". It was basically a single
> contributor effort (himself). One day he simply said to the group, "Here, 
I
> have this new design and architecture for Apache. It adds a lot of
> features." So much of what defines httpd today can find its origin right
> there: modular framework, pools, preforking (and, as such, the initial
> gleaming towards MPMs), extendable API, etc...
>
> In many ways, this was a large code drop. What made it different is that
> there was *support* by the author and the community to work on integrating
> it into the whole. It became, basically, a community effort.
>
> Now compare that with a different scenario... Once httpd had picked up
> steam, and making sure that it was ported to everyone's favorite *nix
> flavor was important, SGI had done work on a set of patches that ported
> httpd to their OS and provided these patches (a set of 10 very large
> patch-files, iirc) to the group. What was clear in those patches is that
> there was no consideration at all on how those patches affected or broke
> anyone else. They rewrote huge swaths of code, optimizing for SGI and
> totally destroying any sort of portability for anyone else. And when we
> responded by, asking for more information, help with chatting with their
 

reporter.a.o Board Report Due Dates

[Alex Harui]

Hi ComDev,

Our new PMC chair was confused by reporter.a.o saying that our board report is 
due on 6/20.  I suppose technically it is, but maybe some language should be 
added to say that reports should/must be filed a week earlier?

Thoughts?
-Alex

Re: The Apache Software Foundation Community Sponsorship Trade with DeveloperWeek

[Alex Harui]

Just to throw a different opinion out there, I wouldn't mind reading and
deleting as many as a dozen marketing-type emails per year if it got the
ASF's name out in front of people that don't already know about us, or
made the ASF appear like a friendly, collegial, foundation.

We might require approval of the content to make sure it doesn't somehow
enable tracking/data-mining, and require an ASF sessions(s) and speaker(s)
so we can market the ASF at their event.

My 2 cents,
-Alex

On 11/30/17, 4:40 AM, "Kevin A. McGrail"  wrote:

>On 11/30/2017 7:38 AM, Bertrand Delacretaz wrote:
>> On Thu, Nov 30, 2017 at 1:15 PM, Kevin A. McGrail 
>>wrote:
>>> ...I wanted to point out that their proposal is to send their copy to
>>>our
>>> members@ list...
>> Which we won't accept, cleary. I think Sharan is suggesting just
>> emailing here and I added that that should be just one email like "FYI
>> we are community sponsors of XYZ". Along with one tweet and mentioning
>> it in the monthly comdev blog news.
>>
>> I that's not enough to be a community sponsor I'd say we just drop this.
>
>+1.  It seems to me like they just want us for a conduit to our members
>and I am worried what their copy will be and how much tracking/data
>mining they will perform..
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>For additional commands, e-mail: dev-h...@community.apache.org
>


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Contribute as a company

[Alex Harui]

On 4/20/17, 10:14 AM, "William Li"  wrote:

>Thanks Ted. No worries on the commitment side. Either way I'd start
>learning and contributing.
>
>If there are ways to check contributions by companies, it could be a
>win-win for both the individuals and the companies who are sponsoring.

Hi William,

What question would a company want to answer that knowing "who committed
what" would matter?

You might be able to mine that information from the logs anyway.

-Alex

Re: Results: ASF Committer Diversity Survey

[Alex Harui]

On 12/21/16, 12:10 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:

>On Wed, Dec 21, 2016 at 1:17 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>> On 12/21/16, 11:05 AM, "Pierre Smits" <pierre.sm...@gmail.com> wrote:
>>
>> >To much work? For whom? In what period?
>> >Does is require a combined effort? A plan? Or just a firing from the
>>hip?
>>
>> Well, I think it would be good to get a new number "soon".  Sounded like
>> Daniel could get a number from commits quickly.  Not sure how hard it
>> would be to add in mailing list activity.  But opening the discussion to
>> where else to look and actually looking made me think it would take
>>longer
>> and more energy than it was worth.  Hopefully folks who earned commit
>> rights for spending time elsewhere occasionally drop by their dev@.
>>They
>> should just so folks can know what is going on only by following dev@.
>>
>> Just my 2 cents though.  I won't be doing the work or stopping anyone
>>from
>> trying.
>>
>
>The biggest hassle with email activity is cross-correlating all of the
>possible
>email aliases for some 6000 people, no longer really practical. committer
>id
>is still easier if there were a way to collect git activity as well as svn
>based
>projects.

Agreed.  I was wondering if the forwarding email address stored at
id.apache.org would net enough to be significant or not.  That's the email
where you received the survey notice.  If you use that to send anything to
an ASF list we add you to the count.

-Alex

Re: Results: ASF Committer Diversity Survey

[Alex Harui]

On 12/21/16, 11:05 AM, "Pierre Smits" <pierre.sm...@gmail.com> wrote:

>To much work? For whom? In what period?
>Does is require a combined effort? A plan? Or just a firing from the hip?

Well, I think it would be good to get a new number "soon".  Sounded like
Daniel could get a number from commits quickly.  Not sure how hard it
would be to add in mailing list activity.  But opening the discussion to
where else to look and actually looking made me think it would take longer
and more energy than it was worth.  Hopefully folks who earned commit
rights for spending time elsewhere occasionally drop by their dev@.  They
should just so folks can know what is going on only by following dev@.

Just my 2 cents though.  I won't be doing the work or stopping anyone from
trying.
-Alex

>
>Best regards,
>
>Pierre Smits
>
>ORRTIZ.COM <http://www.orrtiz.com>
>OFBiz based solutions & services
>
>OFBiz Extensions Marketplace
>http://oem.ofbizci.net/oci-2/
>
>On Wed, Dec 21, 2016 at 6:56 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>> On 12/21/16, 9:01 AM, "Rich Bowen" <rbo...@rcbowen.com> wrote:
>>
>> >
>> >
>> >On 12/21/2016 08:32 AM, A. Soroka wrote:
>> >> Not to say that this isn't a good first step, but that is definitely
>> >>not going to capture a lot of important engagement. At Apache Jena we
>> >>recently elected an excellent committer who has never made a single
>> >>commit. Instead we elected him to recognize his fantastic involvement
>> >>with the community answering questions and helping new users.
>> >>
>> >> I'm not sure what to do about that (measurement-wise) but perhaps as
>>a
>> >>future move, the base list of committers for a project could be joined
>> >>against stats from the mailing lists for that project?
>> >>
>> >
>> >Yes, this was my point exactly. Thanks for articulating. Probably would
>> >need to combine mlist + commit + tickets + ... other stuff? Some
>> >communities have active contributors who spend their time answering
>> >questions on IRC, G+, Facebook, StackOverflow, etc.
>>
>> That's starting to sound like too much work.  Would be nice to get
>>though,
>> but a first approximation of mlist + commit should give us a rough idea
>> for how far off the original 13% response rate number might be.
>>
>> My 2 cents,
>> -Alex
>>
>>


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Results: ASF Committer Diversity Survey

[Alex Harui]

On 12/21/16, 9:01 AM, "Rich Bowen"  wrote:

>
>
>On 12/21/2016 08:32 AM, A. Soroka wrote:
>> Not to say that this isn't a good first step, but that is definitely
>>not going to capture a lot of important engagement. At Apache Jena we
>>recently elected an excellent committer who has never made a single
>>commit. Instead we elected him to recognize his fantastic involvement
>>with the community answering questions and helping new users.
>> 
>> I'm not sure what to do about that (measurement-wise) but perhaps as a
>>future move, the base list of committers for a project could be joined
>>against stats from the mailing lists for that project?
>> 
>
>Yes, this was my point exactly. Thanks for articulating. Probably would
>need to combine mlist + commit + tickets + ... other stuff? Some
>communities have active contributors who spend their time answering
>questions on IRC, G+, Facebook, StackOverflow, etc.

That's starting to sound like too much work.  Would be nice to get though,
but a first approximation of mlist + commit should give us a rough idea
for how far off the original 13% response rate number might be.

My 2 cents,
-Alex

Re: Results: ASF Committer Diversity Survey

[Alex Harui]

On 12/20/16, 6:47 PM, "Matthew Sacks"  wrote:

>Alex, what does this have anything to do with diversity?

I (and maybe others) want to eliminate the argument that the response rate
was too low to be used to draw conclusions.  See [1].

Thinking about this more, we might also want to factor in any committer
who sent an email on an ASF mailing list.  Maybe JIRA as well?  That would
give us a rough number of folks on committers@ who are active.  Sure,
someone who wouldn't be considered active under this criteria could have
still filled out the survey, but it seems like as good a number as any.


Just a thought,
-Alex

[1] https://www.surveygizmo.com/survey-blog/survey-response-rates/

Re: Results: ASF Committer Diversity Survey

[Alex Harui]

On 12/20/16, 8:11 AM, "Rich Bowen"  wrote:

>
>
>On 12/19/2016 08:36 AM, Sharan F wrote:
>> Hello Everyone
>> 
>> A big thank you to everyone that has helped or participated in getting
>> the Committer Diversity Survey out, and also to all the committers that
>> responded to the survey. It has been really good to be able to collect
>> this information and see what it tells us about our committer base.
>> 
>> I've loaded the main data and graphs from the survey onto the Community
>> Development wiki (see link below)
>> 
>> 
>>https://cwiki.apache.org/confluence/display/COMDEV/ASF+Committer+Diversit
>>y+Survey+-+2016
>> 
>> 
>> In total we received 765 responses (out of a 5861 committer base at the
>> time the survey was run) so around a 13% response rate.
>
>It would be useful to pursue Niclas' assertion that most of our
>registered committers are inactive. I'd think that if we define
>"inactive" in some measurable way, we could determine some actual
>numbers around that.
>
>Either way, though, given how anti-survey we have been in the past, 13%
>actually sounds like a pretty good response rate to me.

How hard would it be to generate the count of all apache ids that
committed to any ASF repo in the last N months?

-Alex

Re: What's the plan? What are we here for?

[Alex Harui]

On 12/6/16, 3:36 AM, "Rich Bowen"  wrote:

>On Dec 6, 2016 6:10 AM, "Bertrand Delacretaz" 
>wrote:
>
>I hope we agree on that and I think we do, I'm just slightly worried
>that your initiative might be interpreted in the wrong way.
>
>I am confident that my initiative will be interpreted the wrong way. Seems
>to be the way of things.

Don't know if this will help, but this thread caused me to look up some
definitions of words like "goals", "strategies" and "plans". There seems
to be different interpretations, but I sort of liked the following:


-goal:  Statement of what you want to achieve
-strategy:  The current plan under execution.
-plan:  A set of steps to execute.

In other words, if you have a goal to increase number of committers, you
might have a plan A and a plan B, and the strategy might be to execute on
plan A and fall back to plan B.

So under these definitions, I think ComDev should certainly have goals.
Rich wrote (snipped heavily for brevity):

1) Increase community diversity.

2) Develop tools (documentation, training materials, and software tools)
that projects can use to promote themselves and attract new
participants.

3) Educate projects on the Apache Way, so that they can more richly
experience the organization that they have attached themselves to.

4) Strengthen the bonds between projects and the larger Foundation.

5) It's not about marketing, but we should be working very closely with
marketing (press@) to promote what our projects are doing, and promote
the idea of the ASF as a place where innovation happens.

6) Internal promotion and cheerleading. Many of our projects
have no idea what other projects are doing, and don't care. Doing a
degree of internal cheerleading, along with the education, is critical
for building exprit de corps.

IMO, 1, 3, maybe 4 are goals.  2, 5, 6 are parts of a plan.  The goals
could use some success metrics (closer matching to the world-wide
demographics of developers, fewer wayward projects for the board to
handle).


But I sort of agree with Bertrand that there may not need to be a
well-defined strategy and plans for ComDev.  It is fine for ComDev to have
managers whose job is to facilitate and arbitrate on activities.  Those
people answer the "how can I help" with "here are the goals, here are
things some people are doing, help them out or come up with your own
idea".  But I thought Bertrand's point was to make sure folks are
encourage to come up with their own ideas.  The only measurement is
whether it can be argued as helping achieve the goals, not necessarily
whether it matches up with any steps in plans being executed by others.

I live in a smallish community that is growing because it is a nice place
to live.  Folks move here, bring their volunteer ideas about how to make
living here a bit better, and generally, are told to go for it.  There is
one volunteer group with a few folks who network between all of the other
volunteers and volunteer organizations in this community to try to
coordinate efforts and deal with conflict.  ComDev only has to be that one
group.

My 2 cents,
-Alex

Re: Does GSoC help develop communities?

[Alex Harui]

IMO, rather than gathering statistics, it would be better to gather
stories, tips and advice.  It doesn't seem to me that statistics would be
helpful, folks just need to know that it can have great benefits or great
cost and some ideas of the reasons why.  Even if it hasn't been helpful in
the past for the vast majority of ASF projects, if it benefits some other
minority of projects, the important takeaway is that it can work for
certain reasons, not that it isn't a good idea for your project because it
didn't work for most other projects.  Each project is different.

My 2 cents,
-Alex

On 12/5/16, 9:10 AM, "Suresh Marru"  wrote:

>Hi Rich,
>
>Do you prefer to see cumulative statistics or PMC wise? With a small
>effort, I can get detailed statistics from Apache Airavata. GSoC has been
>great for the project and is one of the primary sources to induct fresh
>blood. We have a decent retention rate, students have stayed around,
>earned committerships, then became PMC Members, graduated and moved onto
>real jobs and still continue to contribute (not always by code though).
>
>Engaging the students and mentoring them takes time, but we have spun it
>around and used it as an opportunity to improve documentation and
>contribution workflow.
>
>Hope  this experience summary helps the discussion, will be happy to
>elaborate and provide specific examples.
>
>Cheers,
>Suresh
>
>> On Dec 5, 2016, at 12:01 PM, Rich Bowen  wrote:
>> 
>> Nobody is suggesting we have a 10 year plan with milestones and
>> deliverables. I'm suggesting that when we do something under the heading
>> of "community development" we have an obligation to make some attempt to
>> measure it to determine if it actually moves us in that direction.
>> 
>> Nobody is saying that we shouldn't participate in GSoC. I'm suggesting
>> that before we promote GSoC to our projects, we should have some numbers
>> (we've been doing this for years. surely there's some numbers that we
>> could gather her?) that show projects that it's worth their time. Or
>> warns them that it might not be.
>> 
>> I don't care how much time individuals spend on GSoC. I care that we are
>> telling projects that it's a worthwhile thing for them to spend *their*
>> time on, and we don't appear to have actually taken the time to find out
>> of that's true.
>> 
>> 
>> On 12/05/2016 08:59 AM, Bertrand Delacretaz wrote:
>>> Hi,
>>> 
>>> On Mon, Dec 5, 2016 at 2:30 PM, Daniel Gruno 
>>>wrote:
 ...The task of ComDev is developing community. If we don't have any
data or
 interest in acquiring such to show that this is in fact helping
towards
 that, then we should consider whether the current strategy is the
right
 thing to focus on
>>> 
>>> I disagree with the need for comdev to have a strategy.
>>> 
>>> At the technical level the ASF doesn't have a strategy, it just
>>> provides space for its projects to exist and flourish.
>>> 
>>> I think comdev can operate in the same way, as a loose group of
>>> volunteers who collectively help develop communities, without
>>> necessarily having a global comdev strategy to follow.
>>> 
>>> Three examples:
>>> 
>>> 1) A small group is running GSoC, which as Uli mentions doesn't cost
>>> the ASF anything and actually brings some money in. GSoC clearly helps
>>> our mission by helping a few community members join the ASF every
>>> year. Exactly how many is not very important if volunteers agree to
>>> run it.
>>> 
>>> 2) Sharan and others have started work on diversity initiatives -
>>> another subset of folks sharing common interests that match the
>>> overall comdev mission.
>>> 
>>> 3) I led a small group to develop our maturity model, I think it's a
>>> very useful tool. I think we made just one change to it in 2016, it's
>>> stable but useful and maintained. Others don't care about that or
>>> didn't have time to help - no problem.
>>> 
>>> You could argue that these things are disjoint but they are all small
>>> steps that help towards our overall mission. We don't need much
>>> coordination between them, IMO just making sure the comdev PMC agrees
>>> with these things happening, and doing out best to unify their
>>> communications channels to create synergies is good enough.
>>> 
>>> Comdev can just provide a space for volunteers to help develop
>>> communities, that's good enough for me. If others want more structured
>>> activities feel free to do them but don't expect all PMC members to
>>> necessarily join or to feel bad if they don't.
>>> 
>>> -Bertrand
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
>> 
>> 
>> -- 
>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>> http://apachecon.com/ - @apachecon
>> 
>
>
>-
>To 

Re: Encouraging Diversity - Update 6

[Alex Harui]

On 11/15/16, 9:03 AM, "Patricia Shanahan"  wrote:

>That should be "example of undesirable behavior". One could obviously
>write a rule that prohibits using words with more than three syllables
>in e-mails.

Personally, I don't think "rules", "standards" and "policies" are in play
here.  The CoC describes what is truly out-of-bounds, but I generally
agree with Noah that there is a lot of stuff that is in-bounds that still
makes participating at Apache an uncomfortable and/or unhappy experience.
But I can't imagine ever achieving consensus on codifying what that is.

I don't think most cultures ever do codify such a thing. I haven't seen a
set of rules for the US or Japan.  I think cultures socially encourage and
discourage certain behavior to reach a certain result.  I would like to
welcome Noah back, and am saddened that some of these emails could easily
be seen as unwelcoming by many people, including myself.  Apache mailing
lists often feel like  one of those bars in the rough part of town that I
am too chicken to go into.  Obviously, enough people frequent those bars
to keep them in business so they aren't violating any rules.  I just wish
Apache mailing lists were more like family-friendly restaurants.  If an
11-year-old hot-shot coder wanted to participate in an ASF project, I
would feel compelled to warn them and his/her parents that the tone on
many mailing lists is not family-friendly.  I wish I didn't feel that way.
 I don't understand why it has to be this way.

-Alex

Re: Distributing ASF Material

[Alex Harui]

On 8/17/16, 1:00 AM, "Sharan Foga"  wrote:

>Hi 
>
>It sounds like there are mixed feelings about allowing this so I will
>respond back to them saying that we'd prefer that they don't distribute
>any ASF material.

From the peanut gallery:  HW seems to be a big sponsor of the ASF.  Either
some individual at HW is acting poorly enough that the ASF needs to
consider cutting ties, or that was an isolated incident and we should
continue to try to improve our relationship with HW, including giving them
another opportunity to help us out and using that opportunity to continue
to educate them on proper positioning of the ASF/HW relationship.

I'd rather have folks make mistakes trying to help and attempt to educate
them (before and after) than for us to miss opportunities to get the word
out, unless the people involved are people we shouldn't be involved with
at all.

My 2 cents,
-Alex

Re: Encouraging More Women to Participate on Apache Projects?

[Alex Harui]

On 5/23/16, 12:18 PM, "tamaonakah...@gmail.com" 
wrote:

Snip...

> Members who receive a great deal of generosity during their growth are
>likely to pay it forward.

I found your entire email (most of which I snipped) to be very
informative.  Thank you for taking the time to write.

-Alex

Re: Encouraging More Women to Participate on Apache Projects?

[Alex Harui]

Also, not specific to software: http://leanin.org

HTH,
-Alex

On 5/23/16, 6:36 AM, "Patricia Shanahan"  wrote:

>Systers, http://anitaborg.org/get-involved/systers/
>
>More generally, the Wikipedia article on "Women in Computing",
>https://en.wikipedia.org/wiki/Women_in_computing, has some possible
>resources.
>
>On 5/23/2016 3:45 AM, Sharan Foga wrote:
>> Hi All
>>
>> Just a quick update. I've sent out an email to the following groups so
>>far:
>>
>> - Pyladies
>> - Phpladies
>> - Women Who Code
>> - Girls Who Code
>> - Black Girls Code
>>
>> I'll post any feedback I get. Also if anyone thinks of any other groups
>> they'd like me to contact then please let me know.
>>
>> Thanks
>> Sharan
>>
>> On 20/05/16 14:26, Sharan Foga wrote:
>>> Thanks very much to everyone for their feedback and support.
>>>
>>> Rich - I will contact these groups to see what feedback and advice
>>> they can give.
>>>
>>> Thanks
>>> Sharan
>>>
>>> On 20/05/16 14:05, Rich Bowen wrote:
 I would suggest that the most constructive thing we could do would be
to
 reach out to pyladies and phpwomen and other similar organizations
 and ask
 for recommendations and assistance in setting up a similar entity
here.
 On May 19, 2016 11:18, "Sharan Foga"  wrote:

> Hi All
>
> I'm interested in finding out how we could encourage more women to
> participate on Apache projects. It's a discussion topic that came up
> last
> week while I was at Apachecon. My understanding is that we don't
> have any
> current strategies in place so I think it could be good to look at
> gathering some ideas about how to tackle the problem and also hear
> about
> any lessons learned from any previous or similar strategies.
>
> What do people think?
>
> Thanks
> Sharan
>
>
>
>>>
>>

Re: Base for presentation

[Alex Harui]

On 5/21/16, 4:29 PM, "Patricia Shanahan"  wrote:
>Good points. Unfortunately, the projects in which I'm currently active
>are not very beginner-friendly.
>
>Could people suggest a few projects that would benefit from, and be able
>to use, relatively inexperienced programmers right now?

Apache Flex.  IMO, we want to be the choice for new programmers as well as
experienced programmers.  Full disclosure: Justin and Harbs and I are all
on the PMC.  Not sure what kind of impression we left on the Sharan
thread, but I honestly don't think I've seen any improper behavior toward
someone based on some demographic attribute.

-Alex

Re: Encouraging More Women to Participate on Apache Projects?

[Alex Harui]

On 5/20/16, 5:26 AM, "Sharan Foga"  wrote:
>>>Hi All
>>>
>>> I'm interested in finding out how we could encourage more women to
>>> participate on Apache projects. It's a discussion topic that came up
>>>last
>>> week while I was at Apachecon. My understanding is that we don't have
>>>any
>>> current strategies in place so I think it could be good to look at
>>> gathering some ideas about how to tackle the problem and also hear
>>>about
>>> any lessons learned from any previous or similar strategies.

FWIW, I know they are gearing up to host a "Girls Who Code" series at the
place I work this summer.  Since I am not female, I do not have an easy
way to influence whether Open Source or Apache is discussed during that
series.  Last year I tried to recruit two of the young ladies who happened
to use the same public transportation I do, but was unsuccessful.  Maybe a
better organized promotion from some female volunteers at Apache could
have better results.

Thanks,
-Alex

Re: ApacheCon CFP review committee

[Alex Harui]

Hi Rich,

I'm on the road with limited internet so I haven't looked, but when are
reviews due?

Thanks,
-Alex

On 2/17/16, 1:51 PM, "Rich Bowen"  wrote:

>By now, you should have received email from the ApacheCon CFP system
>with your system credentials. Note that the email was rather confusingly
>titled "EVENT NAME: Review Site Now Open" which caused me to overlook it
>at first.
>
>Thanks to all who have volunteered for this tasks.
>
>-- 
>Rich Bowen - rbo...@rcbowen.com - @rbowen
>http://apachecon.com/ - @apachecon

Re: ApacheCon CFP, review committee needed

[Alex Harui]

Hi Rich,

Are there going to be tracks and track chairs?  I'm interested in seeing a
track on Client-side topics and am willing to help review talks relating
to that.  If the reviewers need to be Apache-wide, I am probably not be
best person for that.

Thanks,
-Alex

On 2/13/16, 3:57 AM, "Rich Bowen"  wrote:

>Ladies and Gentlemen,
>
>I appear to have dropped the ball on an important aspect of the
>ApacheCon CFP, and your urgent assistance is needed.
>
>I need a small committee of assistants to help rate the talks and select
>the schedule. Please let me know ASAP if you wish to participate.
>
>A reminder: We license the ApacheCon brand, and the Apache brand itself,
>to a third party to produce our event. We act as subject matter experts
>for them, but they make all the final decisions. Being on this committee
>does not mean that we are running the event, or even making the decisions.
>
>Note 2: This committee will be much smaller than last year, so please
>don't be offended if your offer is politely rejected. Having a huge
>content committee caused logistical difficulties in the last few events,
>and LF has requested that we have a smaller number of participants this
>time.
>
>Note C: LF is putting in place a new CFP system, so we won't be mucking
>about with Google Docs this time, for which I'm sure we're all grateful.
>We will, however, need to learn and work with their new system.
>
>Thanks to anybody that can help in this effort.
>
>-- 
>Rich Bowen - rbo...@rcbowen.com - @rbowen
>http://apachecon.com/ - @apachecon

[ApacheCon NA] Client Track

[Alex Harui]

Hi,

What is the appropriate list for discussing possible tracks for ApacheCon?

Some Apache projects, like Flex and Cordova, are more oriented to clients,
applications and front-ends than server-side, backend code.  For this
year's ApacheCon in Vancouver, Flex and Cordova want to propose a track
for client-oriented talks.  Are other projects interested?  If so, please
propose a talk for
the client track and let us know to look for it.

Thanks,
-Alex
Apache Flex

Re: Forming a community of Apache fans in China - Apache China Community

[Alex Harui]

On 11/21/15, 7:06 PM, "William A Rowe Jr"  wrote:

>That was my reaction.  A dev-cn@community.apache. org could be a useful
>discussion vehicle to engage prospects and help with facilitating that
>engagement.  It wouldn't look all that much different than the usual
>English Q here on dev@c a o.

My initial instinct is that per-language mailing lists aren't a good idea.
 But I would not require that folks post in English either.  Otherwise it
feels like saying at ApacheCon that you have to go another room to have a
conversation in your native language.  Even if I can't read what is being
written by others, I can probably pick out a few keywords and at least
have an idea that certain topics are being discussed.

AIUI, while it is best if all discussion about development is on dev@,
only decisions need to be brought back to dev@ (and even then, those
aren't final).  Thus, I think the only requirement is that the result of
any non-English discussion would have to be brought back to dev@ in
English.   That's sort of the way it works for me in any face-to-face
interaction with teams from other countries.  They often discuss amongst
themselves in their native language right in front of me, then one of them
takes the time to explain it to me in English.  The Flex mailing lists
recently had a discussion in German because it just happened that the two
main people involved happened to both be fluent in German.

-Alex

Re: Passion and vigilance in open source

[Alex Harui]

IMO, I believe history does repeat itself, and that there are pendulums
and cycles, but I think the dynamic here is more linear.  Now I certainly
haven’t been involved with open source and Apache for very long, but
having met Roy and heard him describe why Apache was founded and how it
was supposed to be like a potluck/party, I would say that JimJag is just
witnessing the “natural” progression of large organizations in the US.

I’ve seen other organizations have to become “more serious” as the
customer base grows and the stakes get higher.  You sort of have to, in
order to attempt to propagate the vision and messaging to more and more
people.  The famous party games of “telephone” where one person tells
something to another person and by the time the story has been relayed
several times the story has changed is a true human dynamic.  So more
process is put in place, things take longer because they have to be
written and reviewed, etc.

IIRC, there are people in the world who are serial entrepreneurs.  They
start a company, it grows to a certain point, then they decide (or their
board helps them decide) that it isn’t fun any more and they leave and
start another company.  I know folks who are serial code project starters.
 They take a good idea, develop the prototype, get folks excited, a team
is formed, version 1.0 ships, and then during the drudgery work of making
the product mature, they take off for another new idea.  They don’t find
it fun to fix all of the bugs folks expect to be fixed for version 2.0.

So yeah, being at Apache now probably isn’t nearly the fun it was many
years ago when trying to create a legal entity to protect open source was
new and different.  We now know it is possible and are now trying to fix
all the small bugs.

And meanwhile, while your organization matures, some other person starts
up a similar company with a different angle and folks find it new and
different and fun compared to your now-slower process machinery and people
flock to the new and different thing.  There may be aspects of that new
and different variant that will make it the winner for the next
generation, or it may be that they will inevitably have to implement the
same process machinery.  The legal system in the US tends to make that
happen.  So does the US insurance industry.  Lots of young single people
don’t buy health insurance in the US, then they get married and have kids
(i.e., their organization grows and matures and the stakes get higher) and
then they start buying insurance.

So, I don’t know that Apache can ever swing back to being young and fast,
there is just too many people and too much at stake.  But IMO, any project
within GitHub that becomes as important as some of the ASF projects will
have to go down this same road.

To me, the question about ASF’s attractiveness vs GitHub is all about
whether GitHub has something that will still shine through this additional
process that their high profile projects with US corporate customers will
have to take on at some point.  That’s probably worth a separate thread,
and I don’t spend any time on GH to know for myself, but I think I’ve seen
folks say that their UX is better integrated, which is something we could
work on here at the ASF.  I posted a thread a couple of days ago about
Apache FlexJS being used to build a more integrated UX for ASF projects.

So, sorry Jim, the ASF may never be as much fun as it was, but we should
definitely be discussing whether we need to be more popular to our target
customers and how to go about doing that and whether we can learn anything
from GH or other organizations.

A higher-up executive at Starbucks once told me that he was taught to “try
to imagine what the younger guy/gal competing for his job would do.”  Is
GH that younger guy/gal?  GH could just be a flea market.  Corporations
rarely shop at flea markets.  On occasion a vendor refines their product
at a flea market and starts a million dollar company and leaves the flea
market to try to attract corporate customers.  What can the ASF do to make
that vendor want to come to the ASF at that point?  What are the barriers?

-Alex

On 9/23/15, 8:12 AM, "Alexei Fedotov"  wrote:

>... and thanks to the topic starter for the great topic.
>23.09.2015 17:48 пользователь "Jim Jagielski"  написал:
>
>> Yeah, that's pretty much the way I'm looking at it. To me though, just
>> as gravity is what pulls the pendulum back down to its mid-point, for
>> Open Source, it's the "true Open Source" community (or, if you prefer,
>> the "real" one) which acts as gravity, and pulls the pendulum back
>> to 'b'. But if that real community doesn't exist, then the pendulum
>> never swings back.
>>
>> As long as we are talking mechanical analogies, one I like to use isn't
>> the pendulum but rather the fly-ball governor on a Watt steam engine[1].
>> In this case, when the internal temperature gets too high, the spin of
>> the governor speeds up, 

Mailing List Subscriber Count (was Re: Apache Reporter Service)

[Alex Harui]

On 7/16/15, 7:24 AM, "Alex Harui" <aha...@adobe.com> wrote:

>OK.  Thanks for the info.
>
>I might try subsetting the information to not grab the release info and
>run a job once a day to cache the latest for my project on some other
>server.  I’ll reply back on this thread if I ever get it working.
>
>-Alex

OK, I got something working.  It is here [1].

While reporter.a.o was more for board reports, I (and hopefully someday
other Apache folks) have been writing this web app to not only test out
our next generation of Apache Flex known as Apache FlexJS, but also to try
to see if it is possible to create a web app for Apache projects that
unifies and simplifies the project site visitor experience, like some
folks claim GitHub has.

After rummaging through the reporter.a.o code, I realized I could just as
easily cull most of the information I need from public web pages like
people.a.o and dist.a.o and avoid authentication at reporter.a.o, so I did
that, but I’m blocked on a few things so I have some asks, hopefully in
order from easy to hard:

1) I would like to display the subscriber count in the mailing list
panels.  It looks like there is a file reporter.a.o uses called
mailinglists.json that I can’t get at.  Can I get the subscriber counts
without authentication?  If it is ok from a information security
standpoint but nobody has time, if I can  get access to reporter.a.o I’ll
try to learn how to create my own .py file that just gets that file or a
subset of it.  Or if there is some other way I’m open to that as well.

2) Eventually it would be nice to run this on flex.a.o.  But we need a way
to run a data aggregation job on flex.a.o or get cross-domain (CORS)
access from browsers running apps from flex.a.o to other parts of a.o.
What do we have to do to get permission to do one or the other?

3) This prototype currently has a bunch of buttons that jump out of the
app to other a.o sites like issues.a.o, but in theory, we should be able
to extend this web app to run, for example, a simple JIRA web-app written
in FlexJS so the user never needs to leave this UX for issues.a.o.  For
this we would definitely want CORS access to the REST APIs of JIRA
although it might be possible to set up a proxy server on flex.a.o. Again,
what would we have to do to get permission to do one or the other?

Thanks in advance,
-Alex

[1] http://s.apache.org/MYt

Re: What is the legal basis for enforcing release policies at ASF?

[Alex Harui]

On 8/20/15, 5:27 PM, William A Rowe Jr wr...@rowe-clan.net wrote:

It is generally AL code all the time.  I don't know where you invented a
'kick-in' concept, but unless the committers are violating their
ICLA/CCLA,
nothing could be further from the truth.

Committers sometimes make mistakes.  IIRC, Justin recently caught a
mistake where some files accidentally got their non-AL headers replaced
with AL headers.

Large codebase contributions, especially initial podling code grants might
be messy as well until scrubbed and approved for an official ASF release.
I know from experience.

-Alex

Re: What is the legal basis for enforcing release policies at ASF?

[Alex Harui]

On 8/20/15, 9:26 AM, Benson Margulies bimargul...@gmail.com wrote:


However, a quick search reveals that there are precisely zero
occurrences of the word 'release' in version 2.0 of the Apache
License.

So, I don't know what Jim meant by 'licenses kick in at release', but
my view is that putting source in a public Subversion server or git
repo is a publication in the legal sense, and that the Foundation
grants the Apache license to that content, since we nowhere
communicate that we grant some other (lack of) license until the point
of release. To me, the plain sense of Jim's phrase is that, somehow,
the AL does not apply until there's a release, and I can't make heads
or tails of that.

I assumed Jim meant that the public should not feel certain that the AL
header is correct on items found in the repo, but should feel more certain
it is correct for files in a release, since, supposedly, a bit more
scrutiny about the headers happened in creating the release.

IIRC, one of my employer’s lawyers said that the AL applies to any code
written to be under AL whether it has the header or not.  Headers are a
convenient signpost, but are not required to connect licensing and
copyright to lines of code.

-Alex

Re: Can't reporter.a.o automatically detect version number and release date?

[Alex Harui]

On 6/25/15, 7:18 AM, hedh...@gmail.com on behalf of Niclas Hedhman
hedh...@gmail.com on behalf of nic...@hedhman.org wrote:

If the format is published, and the reward of following it would be
that the reporter picks it up automatically, it could lead to swift
adoption ;-)

You might get push back about having to change naming schemes.

I’m interested in a list of all current and past releases for my project.
I was trying to figure out how to mine archive.a.o or the svn log for it.
I’d be willing to maintain an xml file like in DOAP or elsewhere of not
just the last, but all releases and links to their downloads with
“friendly” names for the releases.  Then reporter.a.o could grab from that.

-Alex


On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno humbed...@apache.org
wrote:

 It has been tried, and it did not work.
 People are too inconsistent across projects in how they name their
release
 files, grabbing the version is nigh impossible.
 If we had some form of agreement on how to name files, then it would be
 possible.

 With regards,
 Daniel.


 On 2015-06-25 15:11, Martijn Dashorst wrote:

 Is there a reason why the reporter.a.o can send a message to a release
 manager that it detected a new release, but is incapable of
 determining a version number and release date?

 Martijn





-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Apache Reporter Service

[Alex Harui]

This is a really cool service.  I noticed it wants login creds.  What data
would have to be stripped in order to allow general public access?  What
would it take to get the JSON for the public info?  I’ll write the client
side in Apache Flex.

Thanks,
-Alex

On 3/5/15, 1:39 AM, Daniel Gruno humbed...@apache.org wrote:



On 2015-03-05 01:00, sebb wrote:
 On 4 March 2015 at 07:26, Daniel Gruno humbed...@apache.org wrote:

 On 2015-03-04 01:29, sebb wrote:
 The tool looks cool, but does not handle Apache Commons properly, as
 it calls it Apache Commons BeanUtils.
 BeanUtils is just one of the Commons components (it seems to be
 picking the first component alphabetically).
 This was due to Commons not having any information on the base project
 available in rdf/json, so the system picked what it thought looked
like a
 winner. I have since changed it to just fetch the name from the PMC
data
 instead.

 The JIRA release option does not work well for Commons.
 Each component has a separate JIRA id, but the graph does not show
the id.
 There are other TLPs with multiple JIRA instances and release cycles,
 for example Creadur
 The JIRA stats are in their infancy still, I'll see if I can't make it
more
 useful for Commons this week.
 The JIRA release fetch tool does not report an error for an invalid
JIRA
 id.

 Note that all Commons JIRA ids are in the Category Commons; similarly
 all Creadur instances are in the Category Creadur.
 It would be really useful if the releases could be fetched using the
 Category.

 I am on the PMC for Commons, JMeter and Creadur.
 Only the JMeter display shows the chair person.
 fixed for comons. As for Creadur, whenever someone creates a profile
for the
 How does one create profiles?
 Nothing obvious on the website.

One clicks on the editor icon to the far right of the menu bar. UI
patches are most welcome :)

 project on projects-new.apache.org, the data will automatically start
 projects-new shows

 Apache Commons BeanUtils: 121 committers, 35 PMC members = sub-project

 It does not make sense to include sub-projects in the project list.


 showing up on reporter.a.o.
 That seems to have been done.
 Might be useful to cross-link the two apps and provide some background
 docs on how to use them.


 It would be useful if ASF members could see the data for every PMC -
 but obviously not update PMCs they are not associated with.
 That is how it already is. Use the hot-link feature to access projects
you
 are not on the PMC of, or use the 'statistics' link from Whimsy.
 What hot-link feature?
 I only see tabs for the 3 PMCs I am on.

If you use the whimsy agenda browser, there is a link under info -
statistics for each PMC that leads to reporter.apache.org and shows you
information about that PMC as well. You can also access this manually by
going to https://reporter.apache.org/?pmcid (where pmcid is the LDAP ID
of the PMC, for instance apr, httpd, sling, climate etc).

With regards,
Daniel.

 With regards,
 Daniel.


 On 3 March 2015 at 10:50, Daniel Gruno humbed...@apache.org wrote:
 Hi folks,
 as some of you will have noticed, either by the commits I just made
or
 conversations going on elsewhere, I have started work on a new helper
 system
 for PMCs called the Apache Reporter Service. This is sort of an
external
 addition to Whimsy, and shows various statistics and data for
projects,
 designed to aid chairs (and other lurkers) in viewing and compiling
data
 for
 board reports.

 The system is now live at: https://reporter.apache.org - you will
need to
 be
 a PMC member of a project to view this site, and you will - in
general -
 only be shown data for projects where you are on the PMC.

 The system will show you:
 - Your next report date and the chair of the project
 - PMC and committership changes over the past 3 months, as well as
latest
 additions if 3 months ago
 - The latest releases done this quarter (if added by RMs)
 - Mailing list statistics: number of subscribers as well as number of
 emails
 sent this quarter and the previous
 - JIRA tickets opened/closed this quarter (if correctly mapped
within the
 system)
 - A mock-up of a board report, with the above data compiled into it
(to
 be
 edited heavily by the chair!)

 Quick-navigation (hot-links) can be done by using the LDAP name of a
 project
 in the URL, for instance: https://reporter.apache.org/?apr would
navigate
 directly to the Apache Portable Runtime project if you are on that
PMC
 (or a
 member of the foundation).

 The report mock-up is meant as a help only, not a canonical template
for
 board reports. Vital items, such as community activity and board
issues
 are
 intentionally left for the reporter (chair) to fill out, and heaven
help
 the
 woman/man who submits a report with these fields left as default ;).

 Later today, I plan to enable the distribution watching part of this
 service, which will send reminders to anyone who pushes a release,
that
 they
 should (not required, but if they want to!) add their 

Re: Veto! Veto?

[Alex Harui]

Sorry, I wasn’t clear.  It isn’t whether the nominee is perceived as an
obstructionist, it is whether one or two of the voters is perceived as an
obstructions.

There are communities where everyone gets along, and there are communities
where there is a person one can construe as a ‘difficult person’.  See
this article [1], if you haven’t already.

[1] http://producingoss.com/en/difficult-people.html

The fact is, both consensus approval and majority approval are subject to
abuse.  In consensus, a single individual can misuse the power of the
veto.  In majority approval, a faction can rule over a smaller faction.
IMO, you should have a goal to get consensus and put in a good faith
effort to get there, but it sounds like your project may need to switch to
majority approval if someone is being unreasonable.

But again, be careful:  When voting in people, these people have to work
together “forever” so selecting the wrong person, or ignoring the wishes
of too many people may end up causing more problems in the end. There is
no one right answer, but there is probably a “best answer for your
project and it may not be what other projects do.

-Alex

On 3/21/15, 4:00 AM, Pierre Smits pierre.sm...@gmail.com wrote:

If the majority perceives that a nominee is an obstructionist then it will
be reflected in the voting result. But if the minority - or even only one
voter - perceives that and others don't, then a veto would be a show
stopper for innovation, expansion and merit recognition c.q. privilege
awarding.

I wonder how it can be that democracy is perceived worse than any other
cracy when it comes to people in open source projects in general and ASF
projects in particular. Mature projects shouldn't need to have such a
mechanism when it comes to people. And it doesn't seem to fit in he Apache
Way.

Best regards



Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Sat, Mar 21, 2015 at 5:24 AM, Alex Harui aha...@adobe.com wrote:

 Consensus Approval works great until you have someone who others rightly
 or wrongly perceive as an obstructionist.  Then it just makes the whole
 project the loser.

 At least one project uses majority approval for new members, but a
serious
 attempt is made to make sure that the vote is unanimous anyway.  Those
in
 opposition deserve to be listened to, but if there are only one or two
 against and lots more in favor, then majority approval avoids long
threads
 trying to persuade the one or two.  Sure discussing more to achieve
 Consensus can be better, but you can also lose momentum of the committer
 candidate and momentum of the rest of the community.

 The -1 vote is an alluring drug.  It can be misused by individuals who,
 consciously or not, cannot avoid the temptation to have control rather
 than to collaborate.  But really make sure you listen.  History is full
of
 disasters caused by not listening to that one person.

 -Alex

Re: Veto! Veto?

[Alex Harui]

If person A ‘can’t work’ with person B, in the nomination discussion, if
person A is a reasonable person and sees overwhelming support for person
B, person A should simply vote +0 and try to avoid person B.  It isn’t
like you all work in the same physical office.  Once a group of people
gets large enough, there is always a chance of temporary or long-term
interpersonal conflict between some of the people.  Folks should make
reasonable attempts to show tolerance and get along, but the key for me is
the word “reasonable”.

And this assumes you folks have truly listened to person A.  Is person A
someone who has a better sense of interpersonal dynamics or someone who
has a tendency to hold a grudge?  Why doesn’t person A like person B and
can those who want to vote +1 provide more recent testimony that person B
isn’t going to cause difficulties with every one else that occurred with
person A?  By now person B should have been reasonably active on your
lists.  Any indication of animosity from person B towards person A?

It could just be that person A is the person you’re going to wish never
got voted in.  Or person A is going to turn out to be right and you’ll all
be sorry you used majority approval to let person B in.  How will you
know?  Make sure you and the other voters have thought it through.

-Alex

On 3/21/15, 11:59 AM, Pierre Smits pierre.sm...@gmail.com wrote:

It is sometimes the case that the individual, with power in the community,
can't work with another 'in his eyes difficult' person.

If his contributions are beneficial to the project, if others in the
project can work with that second person in the collegia/civil manner that
is expected in a communityl, how can it be acceptable that that first
person (the one with power who can't work with the other) can block
acceptance with a veto.

Voting against is not the same as vetoing!

Suppose one of you (with power) finds me 'difficult' within this community
(as this community is somewhat similar to any other ASF project). And
suppose I get nominated as PMC member, because of my good contributions
and
of my ability to work with many others.

How would a veto (to have me in) inspire me to do more for the greater
good, but in stead lead to cycles towards being a loss for this community?

Vetoing people isn't a community builder. It doesn't help when it comes to
collaborating. It doesn't help when it comes to diversifying the
community.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Sat, Mar 21, 2015 at 5:45 PM, Marvin Humphrey mar...@rectangular.com
wrote:

 On Sat, Mar 21, 2015 at 8:29 AM, Benson Margulies
bimargul...@gmail.com
 wrote:

  And I emphasize 'range'. There was a talk at Apache Con some years
  back about the idea that civility goes in two directions: we all want
  to express ourselves in collegial and civil ways, and we also have to
  be prepared to accept communications from people with very different
  styles, up to and including some that we might individually find
  somewhat 'difficult.'

 It's sometimes the case that an individual has difficulty fitting into
one
 community, yet fits just fine within another.  It's interesting to
consider
 how group dynamics differ.  What positive conditions are present or
 negative
 conditions absent in the harmonious group that allow it to function
 smoothly?

 In any case, there are no ideal mechanisms for resolving intractable
 personnel
 conflicts.  The best we can do is talk through differences in the hope
that
 misunderstandings can be cleared or behavioral modifications adopted.

 Marvin Humphrey

Re: Veto! Veto?

[Alex Harui]

Consensus Approval works great until you have someone who others rightly
or wrongly perceive as an obstructionist.  Then it just makes the whole
project the loser.

At least one project uses majority approval for new members, but a serious
attempt is made to make sure that the vote is unanimous anyway.  Those in
opposition deserve to be listened to, but if there are only one or two
against and lots more in favor, then majority approval avoids long threads
trying to persuade the one or two.  Sure discussing more to achieve
Consensus can be better, but you can also lose momentum of the committer
candidate and momentum of the rest of the community.

The -1 vote is an alluring drug.  It can be misused by individuals who,
consciously or not, cannot avoid the temptation to have control rather
than to collaborate.  But really make sure you listen.  History is full of
disasters caused by not listening to that one person.

-Alex

On 3/20/15, 6:04 PM, Pierre Smits pierre.sm...@gmail.com wrote:

Hi all,

If I understand the various documents/pages available regarding voting
correctly, voting a new member in can't be vetoed. Likewise is it with
respect to voting for board members. If I have missed a page somewhere,
please point me to it and I stand corrected.

The following document https://community.apache.org/newcommitter.html
states:

A positive result is achieved by Consensus Approval i.e. at least 3 +1
votes and no vetoes.

Any veto must be accompanied by reasoning and be prepared to defend it.
Other members can attempt to encourage them to change.

While this document talks about getting new committers in a project, it
also seem to be applicable when it comes to getting new PMC members and
even who chairs the PMC.

So how can it be that when it comes to projects, vetoes can be expressed
and block innovation or growth?
One of the reasons I heard when discussing this was that it establishes
control or manageability of the projects member list.

Wouldn't a simple majority (more +1 than -1 votes) yield the same result?
If someone would feel that non-acceptance of a new person would benefit
the
project, wouldn’t it be more proper/righteous  that he should put in the
effort and get a majority of votes?

It is understandable why the ASF (and its projects) have the veto
principle
regarding code changes as it ensures that the(released) works of the
project are of a higher quality than the previous work, and that the works
don't change to something else than what is stated in the mission of the
project (meaning that e.g. the primary work of the Apache HTTP project -
httpd can't be converted into e.g. foo widget).
When it comes to people (and organisations), vetoes have proven that it is
a means to force consensus into a certain direction. It might have some
valid grounds when only a few have the biggest gun and they want to keep
others from getting the same gun (and thus rights/power), but in a
environment (as the ASF is) that builds on collaboration it is seems
overkill.

What do you think? Is, when it comes to people, the veto mechanism not out
of place for an ASF project?

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

Oaths and Anthems (was Re: A maturity model for Apache projects)

[Alex Harui]

I think Bertrand’s document is coming along nicely.

This is half serious and half for fun, but while it will be great to have
a maturity model and top-level authoritative documents on the Apache Way,
to me, what would also help is a way to make important things memorizable.
 I sure hope I don’t have to memorize every word of Bertrand’s document
and only use it as a reference.

As I mentioned on one of these threads, the Boy Scouts (and Girl Scouts)
have oaths and “laws” that you have to memorize to be officially accepted
into their communities.  IMO, these very short “documents try to cement
certain keywords in your head so that you at least realize that certain
topics are important to that organization.  It isn’t out to be detailed in
any way.  That’s what these other documents are for.

So, I offer below some oaths, “laws of Apache” and even an anthem derived
mostly by culling words from Bertrand’s document.  I left out anything
from Bertrand’s document like quality and security that I felt folks
should already be practicing in their day job or in other open source
organizations.  I wanted the fewest words so that it could be more easily
memorized and cement in your head the things that make Apache different
from your day job and other open source groups.

Hope you like it.
-Alex

The Committer Oath
I, _, promise to properly record the licensing and copyright of
any code I commit, treat all committers equally, use the mailing list for
communicating with others, only veto code with technical explanations,
help users, fix bugs, and represent myself and not my employer in my
actions.


The PMC Member Oath (assumes you’ve memorized the Committer Oath already).
I, _, promise to ensure the correct licensing and copyright of the
content of releases, treat all PMC members and committers equally, seek
consensus before voting, identify others whose meritorious actions deserve
inclusion as committers or PMC members, and use the private mailing list
only for discussions about people,

- The Laws of Apache -


Apache Releases:
-Are free
-Are PGP-signed
-On dist.apache.org
-Approved by majority vote
-Do not contain compiled code.
-Contain scripts to compile any source that needs compilation.
-Contain correct LICENSE and NOTICE files


Apache Source Code:
-Is recorded in SVN or Git.
-Is not on GitHub (that’s a copy).
-Is available to the public
-Contains correct headers
-Is licensed under an approved license
-Does not depend on external code under certain licenses.


Apache Binary Packages:
-make the Release Manager liable
-contain LICENSE and NOTICE


The Apache Anthem (to the tune of “My Country Tis of Thee” or “God Save
the Queen”)

A-pach-e code for free
Source zip and tar.gz
Signed PGP.

License and Copyright
NOTICE files in sight.
3 plus-1 vote majority
No binary

Please get those headers right
Plus how to build it right
Check dependencies

Source in Subversion tree
Or Git Repositry
On servers in Apa-a-che
Legal history

Re: projects.apache.org overhaul proposal

[Alex Harui]

On 1/15/15, 9:46 AM, Ross Gardler (MS OPEN TECH)
ross.gard...@microsoft.com wrote:

Where are you seeing discouragement of pilot projects?

In the tone and content of the responses on this thread, including this
one where it feels to me you are again using the maintenance and training
costs to make it seem highly unlikely that any pilot program would ever be
accepted.  I understand we are using money from donors and have to be
somewhat conservative, but I don’t know if it really serves the mission of
the ASF to be one of the more conservative customers our projects will
encounter.

IMO, it would be much more encouraging to say “I don’t know much about
OFBiz but if you can find volunteers to put together a pilot program and
show us that it is easy to learn and use and will save us time and money,
we’ll give you an Azure VM to get started.”  How easy something is to
learn is often biased by whether that person is incentivized to learn or
not.

-Alex

Re: projects.apache.org overhaul proposal

[Alex Harui]

On 1/15/15, 6:35 AM, Bertrand Delacretaz bdelacre...@apache.org wrote:

On Thu, Jan 15, 2015 at 3:24 PM, Rich Bowen rbo...@rcbowen.com wrote:
 ...*historically*, when this kind of thing has happened (project
implements,
 thing becomes critical), gradually it becomes the responsibility of
Infra,
 not of the project, to do ongoing maintenance

Yes, this is why I'm reluctant to encourage any initiative that
requires our infrastructure team to support new tools. And I suspect
infra shares that reluctance ;-)

That being said, it's always a question of benefits vs. costs - but if
a simple thing using technologies that every web developer is supposed
to know works the choice is a no-brainer for me.

IMO, that reluctance is the challenge faced by any ASF project that isn’t
yet on the list of what everyone is “supposed to know”.  AIUI, Infra is
also staffed by volunteers so project folks can volunteer to be Infra for
their project’s usage at the ASF.  And if it isn’t “easy” for non-project
Infra folks to grok how the project’s technology works, that is just
another challenge for the project.  One would suspect that they’ll face
the same battle acquiring new customers anyway.

I’d guess that most ASF projects are not yet a standard and want to be the
new standard.  Getting that first testimonial is often key to becoming the
new standard.  It seems wrong for the ASF to discourage establishment of
pilot implementations until the project establishes a track record on some
other set of customers.  IMO, the ability to get an Azure VM is game
changing in this regard.  The project’s committers can take full
responsibility for the pilot program.  All Infra might need to do is
establish one-way or two-way database or file mirrors so the pilot can’t
mess up what works until it is deemed ready.  I’d bet that most of a
project’s customers would do that anyway.

Infra should be encouraged to learn new things if the ROI is established
by the pilot program and includes the cost of training non-project Infra
folks, and those folks should ask for support like any other customer on
that project’s list, and if they don’t get timely and helpful support,
reject the product just like any other customer would.


In summary, the ASF should be a slightly more willing customer for any of
its projects.  Azure VM’s seem to provide a way to do that without adding
more load to Infra.

-Alex

Re: projects.apache.org overhaul proposal

[Alex Harui]

I was probing the notion that it might be to the advantage of the OFBiz
community to just volunteer something instead of being asked.  Maybe the
folks on this list know the other Apache projects better than I do, but I
wouldn’t even know what to ask for.

The project I’m involved in, Apache Flex, might also have the technology
to improve a lot of things at the ASF.  Once the code I’m working on gets
to a certain point, if I need more customers and want to test out the “eat
your own dog food” principle, I may start offering replacements to some of
the web experiences we have at the ASF.  If I can run a live PoC, it will
make it much easier to sell and focus the conversation and maybe even
garner more contributors.  And even if the ASF rejects it, I will have
learned something in the process.  For sure, I will meter the effort I put
into it accordingly so it isn’t a huge deal if it doesn’t get adopted.

-Alex

On 1/14/15, 2:09 PM, Pierre Smits pierre.sm...@gmail.com wrote:

Like some have expressed in earlier messages in this thread this endeavour
could take up some time. Especially when requirements are not clear.

And let's not forget, the OFBiz community volunteers their effort to get
to
a better OFBiz product. They have the tools in place for that. If the ASF
wants something on top of that from the OFBIz community it needs to be
asked there (their mailing lists). Not here. Even if it is assistance with
prototyping a Proof of Concept.

Apart from that, as the building blocks of OFBiz don't use exotic
constructs (it is java, xml, ftl, groovy, when talking languages) I
surmise
an ASF Azure box can suffice. If concessions regarding data storage are
acceptable (integrated derby in stead of external RDBMS) for such a PoC..

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Jan 14, 2015 at 10:30 PM, Alex Harui aha...@adobe.com wrote:

 I’m way outside my area of knowledge, but is there anything stopping the
 OFBiz community from getting an ASF Azure box and trying to prototype
 something?

 -Alex

 On 1/14/15, 10:46 AM, Pierre Smits pierre.sm...@gmail.com wrote:

 You are correct. And I am aware that budgets are limitied. But I don't
 what
 the budget will be nor decide where the money of the ASF flows. I can
only
 ask for some of it regarding a project. And even then, I won't consider
 doing so for something that could be perceived as a pet project of
Pierre
 Smits. If ASF offices do want an OFBiz implementation to work with,
maybe
 they should go ahead and involve both INFRA and the OFBiz community.
 
 I understand the concerns. I myself have them as well when dealing with
 volunteer organisations. But - and apparently - the ASF has this solved
 regarding the INFRA office. The same could be worked out for the other
 solutions and/or services it needs to have in place.
 
 You just need to ask the right questions to the right people.
 
 Best regards,
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Wed, Jan 14, 2015 at 5:34 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
  Maintaining servers costs money. Money has to come from somewhere and
 has
  to be budgeted. We can't just drop a new demand on infra without
 discussing
  it with them and ensuring they have the capacity.
 
  In terms of maintenance of the result Im thinking who makes the
changes
 we
  need as requirements change over time? Somebody needs to be
responsible
 for
  that and we need to be sure it is sustainable. The easier it is to
 maintain
  the easier it is to find someone willing to do it.
 
  As for my suggestion for OfBiz to be applied to operational area of
the
  foundation I said currently unstructured that is the information
is in
  ad-hoc spreadsheets and mailing lists.  OfBiz is, as far as I'm
aware,
  designed for the kinds of functions I listed.
 
  Sent from my Windows Phone
 
 

Re: How can we support a faster release cadence?

[Alex Harui]

My (more than) 2 cents on this topic.  It's going to be really interesting to 
see how the board decides on this sort of thing.

Your plan is completely logical.  Plenty of business operate this way like 
newspapers and car manufacturers.  Everybody knows when the next release is.  
Car manufacturers release next year's models before the absolute end of the 
year maybe to buy some wiggle room if there is a major defect found, but there 
is no skipping a year.  And newspapers can't really skip a day either.  So they 
ship with hopefully minor bugs and newspapers print corrections and car 
manufacturers recall your car.  I remember reading once that 97% of all cars 
have been recalled for some issue.

And I get how having a schedule helps coordinate the core volunteers.

But what is Cordova's plan if a major defect is found too late for the 
schedule?  Would you skip a release?  And what if something more subjective 
comes up like a some user showing up at the last minute and saying they don't 
like the usability or name of something and a grass roots movement grows around 
it.

Somewhere along the way, I picked up the notion that the 72 hour vote was for 
the non-core.  That Apache communities have folks who are busy with their day 
jobs and can't always get to respond in 24 hours.  Several folks have alluded 
to this in the various threads, but nobody has said that it is policy.

If you are a house builder, I don't think you can buy a piece of property and 
start building a house.  I'm pretty sure you have to post Public Notice signs 
on the property and in the paper and hold a public hearing about whether you 
can use the land to build the house you want to build.  Around where I live, I 
rarely ever see anything get fully rejected, and there seems to be a faction 
that wants to fight any development and maybe this process is just so they can 
feel heard, but it seems to be the process.  My sense is that Apache wants us 
to work this way, but the question is whether we must.

Having a four day manufacturing pipeline is definitely problematic (3 days for 
voting, 1 day for mirror propagation) for rapid releases, especially since many 
other open source organizations can ship as soon as it is checked in, but maybe 
this is also part of the Apache Way.  We apply an extra coat of paint, or do 
additional safety checks, or cater to the community members who can't be as 
active because their working on the project isn't their main job.

Thanks for reading,
-Alex


From: Brian LeRoux b...@brian.iomailto:b...@brian.io
Reply-To: bo...@apache.orgmailto:bo...@apache.org 
bo...@apache.orgmailto:bo...@apache.org
Date: Wednesday, February 12, 2014 7:25 PM
To: Apache Board bo...@apache.orgmailto:bo...@apache.org
Cc: dev@community.apache.orgmailto:dev@community.apache.org 
dev@community.apache.orgmailto:dev@community.apache.org
Subject: Re: How can we support a faster release cadence?

I'd like to throw out some thoughts in support of this thinking and help 
explore how we can support faster releases at Apache.

Cordova has bias to shipping. We started shipping on a schedule mid 2011 and 
this was a very deliberate choice, after two years of scattered, and frankly 
reactionary, releases.

At that time we called the project PhoneGap and we realized our offering was 
playing cat and mouse with the very fast moving dependencies of iOS and 
Android. Being reactionary made shipping a fire drill, inevitably drawn out 
since we didn't exercise those muscles enough, and ultimately this made our 
software a risk for adoption. We didn't want to be a risk for adoption. We also 
did not want our volunteer committership killing themselves every time iOS or 
Android landed a patch.

Moving to a schedule acted as a forcing function to exercise those muscles, 
find our cadence, and only positives to the code and community resulted. 
Shipping brought our core together. It meant if we didn't have a fix for a 
feature the branch would land in the next release which is only a month away. 
This built huge confidence in our team by our community. Our code become better 
tested, and more streamlined. A consistent release cadence not only helped us 
find more quality in our code, but that confidence really helped us build our 
committer and developer community. The story is hardly unique: Chrome, Ubuntu, 
Docker, Firefox, and many others have adopted this model in recent years.

I feel anything that can be considered a better practice for higher quality 
code and driving community confidence, and subsequently adoption, really 
embodies Apache ideals.

The current process could be largely automated and the vote doesn't necessarily 
have to be in the form of an email. I've found these past weeks the act of 
voting seems near cultural at Apache so I hope that doesn't sound crazy! I mean 
well.

Another issue I am personally unclear on is the wide variety of artifacts 
destinations that an Apache project can be shipped today. Maven has some of 

Re: How can we support a faster release cadence?

[Alex Harui]

IMO, a more important question is:  Does it fit within the Apache Way of 
Community over Code to have a project release on a particular schedule?  
Because it feels to me that if you have a release cadence then you are saying 
Clock over Community.

I get that having a schedule helps many in the community manage their time and 
expectations, but I am concerned that a schedule without wiggle room means that 
there is less subjectivity to release quality which can be bad.  No matter how 
long it takes to get from a Release Manager starting the packaging to getting 
it on the dist server, someone may find a critical bug in that window.  Telling 
them that they have to wait for the next release is fair but may not serve 
the best interests of the community.

Then, once you allow subjectivity in a release quality discussion, then I think 
you have to give 72 hours because folks are often volunteers and may not have 
the cycles to respond in a shorter time frame, but may still have something 
very important to say, even if you have your 3 +1 votes already.

Similarly, there are questions about whether a release manager should be 
allowed to PGP sign artifacts created on a CI server.

And regarding the steps required to approve a release, it has been my 
experience on every project I've worked on or used that the bug base has a 
unable to reproduce option that gets used often enough to make me believe 
that a few CI/AutomatedTesting servers are not able to fully certify quality.  
IOW, things that work fine on your computer or on the CI or testing servers 
simply may not work on some community member's computer.   And providing a 
window of time for finding that out is part of the current release policy.

If you've ever just missed a bus or train, knowing another one is coming soon 
isn't very satisfying if you're in a hurry.  If the driver sees you running but 
looks at his watch and drives away, how does that make you feel about that 
person and the company he works for?

Thanks,
-Alex

From: Stephen Connolly 
stephen.alan.conno...@gmail.commailto:stephen.alan.conno...@gmail.com
Reply-To: bo...@apache.orgmailto:bo...@apache.org 
bo...@apache.orgmailto:bo...@apache.org
Date: Friday, February 7, 2014 3:02 AM
To: dev@community.apache.orgmailto:dev@community.apache.org 
dev@community.apache.orgmailto:dev@community.apache.org
Subject: How can we support a faster release cadence?

One of the projects I am involved with is the Jenkins project. At Jenkins we 
cut a release of Jenkins every wednesday... assuming the test all pass...
Not every release is as stable as people might desire (the tests don't catch 
everything), hence there is the LTS release line, but none the less, there is a 
major release every 7 days... and if you look at the usage stats (e.g. 
http://stats.jenkins-ci.org/jenkins-stats/svg/201312-jenkins.svg) most users 
actually stick fairly close to the latest release.

I have found that this 7 day release cadence can be really helpful for some 
code bases.

When I started to think about could we follow this model for the Maven project 
as we move towards Maven 4.0, there is one thing that gets in the way... namely 
release votes.

The standard answer is that we could publish snapshots... but those are not 
indented for use by users... and where the cadence can help is that these 
things can be picked up by users.

So what is it that gets in the way with release votes:

* The 72h soft requirement for vote duration

* The actions that a PMC member is required to perform before they can vote. 
See http://www.apache.org/dev/release which states:

 Before voting +1 PMC members are required to download the signed source 
code package, compile it as provided, and test the resulting executable on 
their own platform, along with also verifying that the package meets the 
requirements of the ASF policy on releases.

So how exactly do these things get in the way?

Well as I see it the 72h vote duration isn't necessarily a big deal... we need 
some duration of notice about what is going into the release, there will always 
be people who feel the duration is either too short or two long... but with a 7 
day cadence and maybe a few hours before the release manager closes out the 
vote and then you wait for the release to finished syncing to the mirrors and 
then the release manager gets a chance to verify that the release has synced to 
at least one mirror... you could easily lose half a day's duration in that 
process... oh look the release is out 3.5 days after it was cut... and we're 
cutting another one in 3.5 days... it is likely we will not get much meaningful 
feedback from users in the remaining 3.5 days... so essentially you end up with 
a ping-pong of break... skip... fix since if a bleeding edge user finds an 
issue in 4.0.56 we will have cut 4.0.57 by the time they report it to us and 
the fix ends up in 4.0.58... with a shorter vote duration, say 12h, the 
bleeding edge user reports the issue, we 

Re: Feedback on Flex board report

[Alex Harui]

On 4/26/13 2:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote:

 Hi,
 
 On Fri, Apr 26, 2013 at 11:17 AM, Ross Gardler
 rgard...@opendirective.com wrote:
 I just wanted to thank you for the feedback you provided in your last
 board report with respect to your experiences with moving to Git. This
 kind of information is really useful to those in other projects...
 
 Note that the Flex team's view on Git as they reported it is fairly
 negative - this is totally understandable considering the history of
 how and when the move happened in that project, but other Apache
 projects are not seeing those issues at all.
 
 I suspect this negative view will evolve over time - either the
 project will revert to svn or they will be happy with Git after
 finding their groove. With this in mind, it would be better to post
 that information to http://blogs.apache.org/flex/ as something that's
 valid at this point in time (where we are with Git today), and maybe
 just add the essential, more durable information and links to the
 comdev website.
 
 -Bertrand
It is true that there is less negativity about git every day in the Flex
community.  I doubt we will go back to SVN.

I'm not sure it is worth blogging it.  The draft of the report is captured
on the dev@flex.a.o archives so it is public and searchable.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui