Re: [WG: Code of conduct] Proposal

[Rich Bowen]

> On Jun 23, 2024, at 7:04 PM, B C  wrote:
> 
> I don't understand why I'm seeing these emails.


You’re seeing these emails because you are subscribed to the 
dev@community.apache.org <mailto:dev@community.apache.org> mailing list. If you 
do not wish to be, you can unsubscribe by sending email to 
dev-unsubscr...@community.apache.org 
<mailto:dev-unsubscr...@community.apache.org>




> 
> From: Rich Bowen 
> Sent: Saturday, June 15, 2024 8:57:25 AM
> To: ASF ComDev 
> Subject: Re: [WG: Code of conduct] Proposal
> 
> On Wed, Jun 12, 2024, 22:12 Justin Mclean  wrote:
> 
>> Hi,
>> 
>> Can you give us some idea of what you have already changed in the CoC
>> text, I expected a little more from the version control history.
>> 
> 
> I changed "community leaders" to PMC members a few places. I believe that's
> the only chance I made but I may be forgetting something. I'll send a diff
> once I'm back at my desk,unless someone beats me to it.
> 
>> 

Re: [WG: Code of conduct] Proposal

[B C]

I don't understand why I'm seeing these emails.

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Rich Bowen 
Sent: Saturday, June 15, 2024 8:57:25 AM
To: ASF ComDev 
Subject: Re: [WG: Code of conduct] Proposal

On Wed, Jun 12, 2024, 22:12 Justin Mclean  wrote:

> Hi,
>
> Can you give us some idea of what you have already changed in the CoC
> text, I expected a little more from the version control history.
>

I changed "community leaders" to PMC members a few places. I believe that's
the only chance I made but I may be forgetting something. I'll send a diff
once I'm back at my desk,unless someone beats me to it.

>

Re: [WG: Code of conduct] Proposal

[Rich Bowen]

On Wed, Jun 12, 2024, 22:12 Justin Mclean  wrote:

> Hi,
>
> Can you give us some idea of what you have already changed in the CoC
> text, I expected a little more from the version control history.
>

I changed "community leaders" to PMC members a few places. I believe that's
the only chance I made but I may be forgetting something. I'll send a diff
once I'm back at my desk,unless someone beats me to it.

>

Re: [WG: Code of conduct] Proposal

[Justin Mclean]

Hi,

Can you give us some idea of what you have already changed in the CoC text, I 
expected a little more from the version control history.

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

Re: [WG: Code of conduct] Proposal

[Rich Bowen]

Cool. Started here: 
https://github.com/apache/comdev-working-groups/tree/main/wg-code-of-conduct

Let’s discuss specific changes to the text here, with a [WG: Code of conduct] 
tag in email subjects.

Thanks.

— 
Rich Bowen
rbo...@rcbowen.com

Re: [WG: Code of conduct] Proposal

[Justin Mclean]

Hi,

I can also help out here.

Kind Regards,
Justin

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

Re: [WG: Code of conduct] Proposal

[Craig Russell]

> On Jun 11, 2024, at 07:17, Rich Bowen  wrote:
> 
>> 
>> On Jun 11, 2024, at 9:55 AM, Craig Russell  wrote:
>> 
>> 
>> 
>>> On Jun 11, 2024, at 06:31, Rich Bowen  wrote:
>>> 
>>>> On Jun 11, 2024, at 6:05 AM, Bertrand Delacretaz  
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>>>>> ...Many ASF projects do not have a code of conduct, and push this up to 
>>>>> the Foundation. This mostly seems
>>>>> to work, in practice, most of the time, but the public *perception* is 
>>>>> just that they don’t have one...
>>>> 
>>>> I think this should be handled like
>>>> https://security.apache.org/projects/ : projects CAN have their own
>>>> code of conduct page and contact address, and if they don't they MUST
>>>> point to the ASF's page and contact address
>>> 
>>> While I agree in principle, ComDev cannot say MUST to any project. We are a 
>>> PMC, not a Board/President committee, and act only in an advisory capacity.
>>> 
>>> (I know you know this, but it bears reminding and repeating this for others 
>>> watching this conversation.)
>> 
>> I suppose if the board wants to take some action it could pass a resolution…
> 
> 
> The work that this working group needs to do is, I believe, a prerequisite to 
> asking the board to make such a resolution. If you feel differently, don’t 
> wait for me, but that’s how I see things.

We are in agreement. The board should act only after there is agreement on a 
proposal that has been carefully reviewed.

Craig

> 
> —Rich (speaking with my fictional “hat” as a Member, not as a Director)

Craig L Russell
c...@apache.org

Re: [WG: Code of conduct] Proposal

[Rich Bowen]

> On Jun 11, 2024, at 9:55 AM, Craig Russell  wrote:
> 
> 
> 
>> On Jun 11, 2024, at 06:31, Rich Bowen  wrote:
>> 
>>> On Jun 11, 2024, at 6:05 AM, Bertrand Delacretaz  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>>>> ...Many ASF projects do not have a code of conduct, and push this up to 
>>>> the Foundation. This mostly seems
>>>> to work, in practice, most of the time, but the public *perception* is 
>>>> just that they don’t have one...
>>> 
>>> I think this should be handled like
>>> https://security.apache.org/projects/ : projects CAN have their own
>>> code of conduct page and contact address, and if they don't they MUST
>>> point to the ASF's page and contact address
>> 
>> While I agree in principle, ComDev cannot say MUST to any project. We are a 
>> PMC, not a Board/President committee, and act only in an advisory capacity.
>> 
>> (I know you know this, but it bears reminding and repeating this for others 
>> watching this conversation.)
> 
> I suppose if the board wants to take some action it could pass a resolution…


The work that this working group needs to do is, I believe, a prerequisite to 
asking the board to make such a resolution. If you feel differently, don’t wait 
for me, but that’s how I see things.

—Rich (speaking with my fictional “hat” as a Member, not as a Director)

Re: [WG: Code of conduct] Proposal

[Craig Russell]

> On Jun 11, 2024, at 06:31, Rich Bowen  wrote:
> 
>> On Jun 11, 2024, at 6:05 AM, Bertrand Delacretaz  
>> wrote:
>> 
>> Hi,
>> 
>> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>>> ...Many ASF projects do not have a code of conduct, and push this up to the 
>>> Foundation. This mostly seems
>>> to work, in practice, most of the time, but the public *perception* is just 
>>> that they don’t have one...
>> 
>> I think this should be handled like
>> https://security.apache.org/projects/ : projects CAN have their own
>> code of conduct page and contact address, and if they don't they MUST
>> point to the ASF's page and contact address
> 
> While I agree in principle, ComDev cannot say MUST to any project. We are a 
> PMC, not a Board/President committee, and act only in an advisory capacity.
> 
> (I know you know this, but it bears reminding and repeating this for others 
> watching this conversation.)

I suppose if the board wants to take some action it could pass a resolution...

Craig

> 
> —Rich
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 
> <mailto:dev-unsubscr...@community.apache.org>
> For additional commands, e-mail: dev-h...@community.apache.org 
> <mailto:dev-h...@community.apache.org>
Craig L Russell
c...@apache.org

Re: [WG: Code of conduct] Proposal

[Rich Bowen]

> On Jun 11, 2024, at 6:05 AM, Bertrand Delacretaz  
> wrote:
> 
> Hi,
> 
> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>> ...Many ASF projects do not have a code of conduct, and push this up to the 
>> Foundation. This mostly seems
>> to work, in practice, most of the time, but the public *perception* is just 
>> that they don’t have one...
> 
> I think this should be handled like
> https://security.apache.org/projects/ : projects CAN have their own
> code of conduct page and contact address, and if they don't they MUST
> point to the ASF's page and contact address

While I agree in principle, ComDev cannot say MUST to any project. We are a 
PMC, not a Board/President committee, and act only in an advisory capacity.

(I know you know this, but it bears reminding and repeating this for others 
watching this conversation.)

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

Re: [WG: Code of conduct] Proposal

[Craig Russell]

> On Jun 11, 2024, at 03:05, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>> ...Many ASF projects do not have a code of conduct, and push this up to the 
>> Foundation. This mostly seems
>> to work, in practice, most of the time, but the public *perception* is just 
>> that they don’t have one...
> 
> I think this should be handled like
> https://security.apache.org/projects/ : projects CAN have their own
> code of conduct page and contact address, and if they don't they MUST
> point to the ASF's page and contact address

I agree. I'll volunteer to be part of the working group to make this happen.

Craig
> 
> -Bertrand
> 
> -
> 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: [WG: Code of conduct] Proposal

[Bertrand Delacretaz]

Hi,

On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
> ...Many ASF projects do not have a code of conduct, and push this up to the 
> Foundation. This mostly seems
> to work, in practice, most of the time, but the public *perception* is just 
> that they don’t have one...

I think this should be handled like
https://security.apache.org/projects/ : projects CAN have their own
code of conduct page and contact address, and if they don't they MUST
point to the ASF's page and contact address

-Bertrand

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

[WG: Code of conduct] Proposal

[Rich Bowen]

Hi, folks,

At our board face-to-face meeting in Bratislava last weekend, the topic of a 
code of conduct was raised. Without getting into all of the historical 
confusion around our code of conduct, I have a proposal for a working group:

TL;DR:

We should create a recommended template Code of Conduct that projects could 
tweak and adopt.

Background:

Many ASF projects do not have a code of conduct, and push this up to the 
Foundation. This mostly seems to work, in practice, most of the time, but the 
public *perception* is just that they don’t have one. Meanwhile, the ASF Code 
of Conduct - https://apache.org/foundation/policies/conduct.html - lacks a 
specific escalation path, and doesn’t leave room for project-specific processes.

Proposal:

The Code of Conduct working group will be a outcome-focused[1] effort to start 
with the Contributor Covenant V 2.1 [2] and turn it into a template which ASF 
project could adopt as-is, or make small tweaks to for their specific project. 
This task consists of several steps:

0) Create a section under https://github.com/apache/comdev-working-groups 

1) Edit the CCv2.1 to put ASF-specific language in (PMC, Project, Board, etc)

2) Identify sections that need to be updated/altered to reflect the ASF way of 
doing things. Eg, Clarify the Scope section for ASF norms, and work out the 
escalation path for when/if a project wishes to escalate a complaint to the 
Foundation. (Which would require understanding and working with the existing 
process, so that we are not creating new work for the folks that already do 
that work.)

3) Run it by a few projects and see what they think

4) Provide it as a template on community.apache.org 
<http://community.apache.org/> as a proposed/suggested template.

What this isn’t:

This is NOT an effort to create a committee that would impose and/or enforce 
community of codes on various projects, or at the Foundation level. Any effort 
to turn it into that will be … unpopular. To say the least.

Next steps:

If anyone is interested in doing this work with me, please jump in and get 
started. I do plan to spend some time on this in the coming weeks, but won’t 
have time to get started on it until next week at the very earliest. But don’t 
feel that you have to wait for me if you are interested in the topic.

—Rich

[1] By outcome-focused, what I mean is that it has a specific task, which, upon 
completion, the WG would dissolve 

[2] 
https://www.contributor-covenant.org/version/2/1/code_of_conduct/code_of_conduct.md

— 
Rich Bowen
rbo...@rcbowen.com

Re: Code of Conduct - Over Responding

[Joseph Schaefer]

Lgtm!

Sent from my iPhone

> On Jun 8, 2016, at 6:27 PM, Niall Pemberton  wrote:
> 
> 
>> On Tue, Jun 7, 2016 at 1:49 AM, Rich Bowen  wrote:
>> 
>> 
>> On 06/06/2016 05:21 PM, Niall Pemberton wrote:
>> > On Mon, Jun 6, 2016 at 1:16 AM, Rich Bowen  wrote:
>> >
>> >> The challenge with a CoC is knowing when to quit before becoming the
>> >> thought police. Also, it should be things that are measurable and
>> >> enforceable. I don't think this is either.
>> >>
>> >> What you are suggesting is really good advice, but isn't something we can
>> >> enforce with policy.
>> >>
>> >
>> > The Code of Conduct is mostly not "measurable and enforceable" and just
>> > contains good advice - of the seven sections the only we can enforce is the
>> > "Be careful in the words that we choose" section. I dont have a problem
>> > with that because I see it as a tool to encourage people, rather than just
>> > something to be enforced.
>> 
>> 
>> 
>> Yes, I suppose you're right.
>> 
>> Perhaps such an injunction could indeed be added to that section. Do you
>> have a recommended patch?
> 
> I came up with adding the following in the "Be concise" section (attached as 
> a patch):
> 
> "Try not to dominate a thread, you don't have to respond to everyone. Pause 
> between sending emails to give others an opportunity to contribute to the 
> debate."
> 
> Niall
> 
>  
>> 
>> 
>> --
>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>> http://apachecon.com/ - @apachecon
> 

Re: Code of Conduct - Over Responding

[Niall Pemberton]

On Tue, Jun 7, 2016 at 1:49 AM, Rich Bowen  wrote:

>
>
> On 06/06/2016 05:21 PM, Niall Pemberton wrote:
> > On Mon, Jun 6, 2016 at 1:16 AM, Rich Bowen  wrote:
> >
> >> The challenge with a CoC is knowing when to quit before becoming the
> >> thought police. Also, it should be things that are measurable and
> >> enforceable. I don't think this is either.
> >>
> >> What you are suggesting is really good advice, but isn't something we
> can
> >> enforce with policy.
> >>
> >
> > The Code of Conduct is mostly not "measurable and enforceable" and just
> > contains good advice - of the seven sections the only we can enforce is
> the
> > "Be careful in the words that we choose" section. I dont have a problem
> > with that because I see it as a tool to encourage people, rather than
> just
> > something to be enforced.
>
>
>
> Yes, I suppose you're right.
>
> Perhaps such an injunction could indeed be added to that section. Do you
> have a recommended patch?
>

I came up with adding the following in the "Be concise" section (attached
as a patch):

"Try not to dominate a thread, you don't have to respond to everyone. Pause
between sending emails to give others an opportunity to contribute to the
debate."

Niall



>
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>
>

Re: Code of Conduct - Over Responding

[Rich Bowen]

On 06/06/2016 05:21 PM, Niall Pemberton wrote:
> On Mon, Jun 6, 2016 at 1:16 AM, Rich Bowen  wrote:
> 
>> The challenge with a CoC is knowing when to quit before becoming the
>> thought police. Also, it should be things that are measurable and
>> enforceable. I don't think this is either.
>>
>> What you are suggesting is really good advice, but isn't something we can
>> enforce with policy.
>>
> 
> The Code of Conduct is mostly not "measurable and enforceable" and just
> contains good advice - of the seven sections the only we can enforce is the
> "Be careful in the words that we choose" section. I dont have a problem
> with that because I see it as a tool to encourage people, rather than just
> something to be enforced.



Yes, I suppose you're right.

Perhaps such an injunction could indeed be added to that section. Do you
have a recommended patch?


-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon



signature.asc
Description: OpenPGP digital signature

Re: Code of Conduct - Over Responding

[Niall Pemberton]

On Mon, Jun 6, 2016 at 1:16 AM, Rich Bowen  wrote:

> The challenge with a CoC is knowing when to quit before becoming the
> thought police. Also, it should be things that are measurable and
> enforceable. I don't think this is either.
>
> What you are suggesting is really good advice, but isn't something we can
> enforce with policy.
>

The Code of Conduct is mostly not "measurable and enforceable" and just
contains good advice - of the seven sections the only we can enforce is the
"Be careful in the words that we choose" section. I dont have a problem
with that because I see it as a tool to encourage people, rather than just
something to be enforced.

Niall




> On Jun 5, 2016 8:00 PM, "Niall Pemberton" 
> wrote:
>
> > Hi,
> >
> > I really like the code of conduct, but I think it would be good to
> include
> > something about sending too many emails. Sometimes you get people who
> > dominate a thread, responding to almost everyone and they drain the
> energy
> > of others to take part.
> >
> > My suggestion is to add a sentence to the "Be concise" section, perhaps
> > something like the following:
> >
> > "Try not to dominate a thread, you don't have to respond to everyone.
> Pause
> > between sending emails to give others an opportunity to contribute to the
> > debate."
> >
> > WDYT?
> >
> > Niall
> >
>

Re: Code of Conduct - Over Responding

[Mark Thomas]

On 06/06/2016 01:16, Rich Bowen wrote:
> The challenge with a CoC is knowing when to quit before becoming the
> thought police. Also, it should be things that are measurable and
> enforceable. I don't think this is either.
> 
> What you are suggesting is really good advice, but isn't something we can
> enforce with policy.

While the CoC might not be the best place for this good advice, there
are other places where it might work better:
http://community.apache.org/contributors/etiquette
http://www.apache.org/dev/contrib-email-tips

Mark

> On Jun 5, 2016 8:00 PM, "Niall Pemberton"  wrote:
> 
>> Hi,
>>
>> I really like the code of conduct, but I think it would be good to include
>> something about sending too many emails. Sometimes you get people who
>> dominate a thread, responding to almost everyone and they drain the energy
>> of others to take part.
>>
>> My suggestion is to add a sentence to the "Be concise" section, perhaps
>> something like the following:
>>
>> "Try not to dominate a thread, you don't have to respond to everyone. Pause
>> between sending emails to give others an opportunity to contribute to the
>> debate."
>>
>> WDYT?
>>
>> Niall
>>
> 

RE: Code of Conduct - Over Responding

[Ross Gardler]

+1



This is not really a CoC issue, more of a best practice one.



Sent from my Windows 10 phone



From: Rich Bowen<mailto:rbo...@rcbowen.com>
Sent: Sunday, June 5, 2016 5:17 PM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Re: Code of Conduct - Over Responding



The challenge with a CoC is knowing when to quit before becoming the
thought police. Also, it should be things that are measurable and
enforceable. I don't think this is either.

What you are suggesting is really good advice, but isn't something we can
enforce with policy.
On Jun 5, 2016 8:00 PM, "Niall Pemberton"  wrote:

> Hi,
>
> I really like the code of conduct, but I think it would be good to include
> something about sending too many emails. Sometimes you get people who
> dominate a thread, responding to almost everyone and they drain the energy
> of others to take part.
>
> My suggestion is to add a sentence to the "Be concise" section, perhaps
> something like the following:
>
> "Try not to dominate a thread, you don't have to respond to everyone. Pause
> between sending emails to give others an opportunity to contribute to the
> debate."
>
> WDYT?
>
> Niall
>

Re: Code of Conduct - Over Responding

[Rich Bowen]

The challenge with a CoC is knowing when to quit before becoming the
thought police. Also, it should be things that are measurable and
enforceable. I don't think this is either.

What you are suggesting is really good advice, but isn't something we can
enforce with policy.
On Jun 5, 2016 8:00 PM, "Niall Pemberton"  wrote:

> Hi,
>
> I really like the code of conduct, but I think it would be good to include
> something about sending too many emails. Sometimes you get people who
> dominate a thread, responding to almost everyone and they drain the energy
> of others to take part.
>
> My suggestion is to add a sentence to the "Be concise" section, perhaps
> something like the following:
>
> "Try not to dominate a thread, you don't have to respond to everyone. Pause
> between sending emails to give others an opportunity to contribute to the
> debate."
>
> WDYT?
>
> Niall
>

Code of Conduct - Over Responding

[Niall Pemberton]

Hi,

I really like the code of conduct, but I think it would be good to include
something about sending too many emails. Sometimes you get people who
dominate a thread, responding to almost everyone and they drain the energy
of others to take part.

My suggestion is to add a sentence to the "Be concise" section, perhaps
something like the following:

"Try not to dominate a thread, you don't have to respond to everyone. Pause
between sending emails to give others an opportunity to contribute to the
debate."

WDYT?

Niall

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

I have done enough. If you feel that is not the case to satisfy you
bureaucratic need, you go ahead and scratch that itch.

Best regards,

Pierre Smits

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

On Fri, Jul 10, 2015 at 2:19 PM, Tim Williams  wrote:

> On Fri, Jul 10, 2015 at 10:56 AM, Pierre Smits 
> wrote:
> > Tim,
> >
> > It seems you're rather fond of it.
>
> Huh? I'm not sure what "it" is or why you're making observations about
> what I'm fond of.
>
> > Quite the number of posters in this
> > thread are particpating in either body, or both. I feel confident that
> they
> > can take it as input from here and discuss appropriate follow-up in their
> > specific mailing lists.
>
> Umm... that's not how our little do-ocracy works dood.  I doubt I'm
> the only one that finds it remarkably unrewarding to help someone who
> has an itch they're unwilling to scratch themselves.
>
> --tim
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Tim Williams]

On Fri, Jul 10, 2015 at 10:56 AM, Pierre Smits  wrote:
> Tim,
>
> It seems you're rather fond of it.

Huh? I'm not sure what "it" is or why you're making observations about
what I'm fond of.

> Quite the number of posters in this
> thread are particpating in either body, or both. I feel confident that they
> can take it as input from here and discuss appropriate follow-up in their
> specific mailing lists.

Umm... that's not how our little do-ocracy works dood.  I doubt I'm
the only one that finds it remarkably unrewarding to help someone who
has an itch they're unwilling to scratch themselves.

--tim

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[jan i]

On 10 July 2015 at 12:56, Pierre Smits  wrote:

> Tim,
>
> It seems you're rather fond of it. Quite the number of posters in this
> thread are particpating in either body, or both. I feel confident that they
> can take it as input from here and discuss appropriate follow-up in their
> specific mailing lists.
>
I you want board to make a change you need to make a proposal to board@
otherwise it is most likely not going to happen.

rgds
jan i.


>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jul 10, 2015 at 12:37 PM, Tim Williams 
> wrote:
>
> > On Fri, Jul 10, 2015 at 10:23 AM, Pierre Smits 
> > wrote:
> > > Branko,
> > >
> > > I am confident that the existing project with bylaws, policies and/or
> > > standing rules formalised has had its share of discussions regarding
> > > applicability of elements therein.. And have resolved those. I guess
> that
> > > when such an element is either to vague or to restrictive so that the
> > > situation becomes untenable to move things forward, the community will
> > find
> > > ways to resolve it.
> > >
> > > This thread is about:
> > >
> > >
> > >- why does the Board tasks projects to create a set of bylaws for
> some
> > >graduating podlings (when so many seem to feel that it doesn't add
> > value);
> > >- and when it does, why doesn't it  follow up on the task or request
> > the
> > >VP of the project to report on its progress until the task is
> > completed.
> > >
> > > It has to come from somewhere. It seems to come to light during the
> > > incubation phase. Don't mentors advice properly?
> >
> > I reckon the answer to these questions is simply that we've all
> > realized over a long period of time that project-specific bylaws -
> > while once popular and thought necessary - aren't desirable.  We
> > thought they were necessary a decade ago and over the course of time
> > realized not so much. And, while we've all come to that realization,
> > no one has taken the time to change the TLP resolution to reflect
> > that. And that's likely because most of us don't have bureaucratic
> > itches - you apparently do, so why not just ask the incubator
> > PMC/board to drop that paragraph?
> >
> > Thanks,
> > --tim
> >
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Tim,

It seems you're rather fond of it. Quite the number of posters in this
thread are particpating in either body, or both. I feel confident that they
can take it as input from here and discuss appropriate follow-up in their
specific mailing lists.

Best regards,

Pierre Smits

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

On Fri, Jul 10, 2015 at 12:37 PM, Tim Williams  wrote:

> On Fri, Jul 10, 2015 at 10:23 AM, Pierre Smits 
> wrote:
> > Branko,
> >
> > I am confident that the existing project with bylaws, policies and/or
> > standing rules formalised has had its share of discussions regarding
> > applicability of elements therein.. And have resolved those. I guess that
> > when such an element is either to vague or to restrictive so that the
> > situation becomes untenable to move things forward, the community will
> find
> > ways to resolve it.
> >
> > This thread is about:
> >
> >
> >- why does the Board tasks projects to create a set of bylaws for some
> >graduating podlings (when so many seem to feel that it doesn't add
> value);
> >- and when it does, why doesn't it  follow up on the task or request
> the
> >VP of the project to report on its progress until the task is
> completed.
> >
> > It has to come from somewhere. It seems to come to light during the
> > incubation phase. Don't mentors advice properly?
>
> I reckon the answer to these questions is simply that we've all
> realized over a long period of time that project-specific bylaws -
> while once popular and thought necessary - aren't desirable.  We
> thought they were necessary a decade ago and over the course of time
> realized not so much. And, while we've all come to that realization,
> no one has taken the time to change the TLP resolution to reflect
> that. And that's likely because most of us don't have bureaucratic
> itches - you apparently do, so why not just ask the incubator
> PMC/board to drop that paragraph?
>
> Thanks,
> --tim
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Tim Williams]

On Fri, Jul 10, 2015 at 10:23 AM, Pierre Smits  wrote:
> Branko,
>
> I am confident that the existing project with bylaws, policies and/or
> standing rules formalised has had its share of discussions regarding
> applicability of elements therein.. And have resolved those. I guess that
> when such an element is either to vague or to restrictive so that the
> situation becomes untenable to move things forward, the community will find
> ways to resolve it.
>
> This thread is about:
>
>
>- why does the Board tasks projects to create a set of bylaws for some
>graduating podlings (when so many seem to feel that it doesn't add value);
>- and when it does, why doesn't it  follow up on the task or request the
>VP of the project to report on its progress until the task is completed.
>
> It has to come from somewhere. It seems to come to light during the
> incubation phase. Don't mentors advice properly?

I reckon the answer to these questions is simply that we've all
realized over a long period of time that project-specific bylaws -
while once popular and thought necessary - aren't desirable.  We
thought they were necessary a decade ago and over the course of time
realized not so much. And, while we've all come to that realization,
no one has taken the time to change the TLP resolution to reflect
that. And that's likely because most of us don't have bureaucratic
itches - you apparently do, so why not just ask the incubator
PMC/board to drop that paragraph?

Thanks,
--tim

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Branko,

I am confident that the existing project with bylaws, policies and/or
standing rules formalised has had its share of discussions regarding
applicability of elements therein.. And have resolved those. I guess that
when such an element is either to vague or to restrictive so that the
situation becomes untenable to move things forward, the community will find
ways to resolve it.

This thread is about:


   - why does the Board tasks projects to create a set of bylaws for some
   graduating podlings (when so many seem to feel that it doesn't add value);
   - and when it does, why doesn't it  follow up on the task or request the
   VP of the project to report on its progress until the task is completed.

It has to come from somewhere. It seems to come to light during the
incubation phase. Don't mentors advice properly?

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 Tue, Jul 7, 2015 at 3:11 PM, Branko Čibej  wrote:

> Pierre, I could find any number of euphemisms to say the same thing, but
> I prefer to say what I mean and not beat about the bush.
>
> To give you an idea where my disgust comes from: Every project here that
> I know of that has bylaws about decision-making has some kind of
> fundamental problem and constant tensions in the community. Now some
> people may think that extra rules serve to keep problems in check, but
> IMO they just make things worse.
>
> -- Brane
>
>
> On 06.07.2015 23:40, Konstantin Boudnik wrote:
> > That's called 'difference of opinions'. Nobody is entitled to like
> others'
> > viewpoints. In fact, there are certain viewpoints that hardly can cause
> > anything but regurgitation in a sane human being. On the hand, no one can
> > denied anyone a right to express their opinions.
> >
> > Cos
> >
> > On Mon, Jul 06, 2015 at 12:10PM, Pierre Smits wrote:
> >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> >> statement of being disgusted by the viewpoint of others on the matter. I
> >> hope you recover from it soon.
> >>
> >> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
> >>
> >>> On 04.07.2015 18:34, Pierre Smits wrote:
> >>>> Having done a cursory review of the incubator reports to the board for
> >>>> this year (January till May/June 2015), I found that only the SAMOA
> >>>> podling reported working on a project set of bylaws, which without
> >>>> knowing details could encompass and/or incorporate the code of
> conduct.
> >>> I find myself disgusted by this widespread assumption that each project
> >>> needs its own bylaws. WTF for? Are not ASF policies and practices
> enough
> >>> for everyone? What sort of bylaws could you possibly invent that are
> >>> both a useful extension of these policies and practices /and/ are not
> >>> applicable to other projects?
> >>>
> >>> Per-project bylaws are just a tool for fragmenting the ASF community,
> in
> >>> other words, they're a bad idea; paper-shuffling at its most useless.
> >>>
> >>> -- Brane
> >>>
>
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Nice. I like proza as well. Before long we'll embark on the path, where we
only see multi-interpretable quotes and we quibble over semantics.

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 Tue, Jul 7, 2015 at 10:01 PM, Konstantin Boudnik  wrote:

> Hopefully you don't mind me helping with a colorful euphemisms here.
> In the words of immortal Tao De Jing
>
>  When government is lazy and informal
>  The people are kind and honest;
>  When government is efficient and severe
>  The people are discontented and deceitful.
>
> Cos
>
> On Tue, Jul 07, 2015 at 03:11PM, Branko Čibej wrote:
> > Pierre, I could find any number of euphemisms to say the same thing, but
> > I prefer to say what I mean and not beat about the bush.
> >
> > To give you an idea where my disgust comes from: Every project here that
> > I know of that has bylaws about decision-making has some kind of
> > fundamental problem and constant tensions in the community. Now some
> > people may think that extra rules serve to keep problems in check, but
> > IMO they just make things worse.
> >
> > -- Brane
> >
> >
> > On 06.07.2015 23:40, Konstantin Boudnik wrote:
> > > That's called 'difference of opinions'. Nobody is entitled to like
> others'
> > > viewpoints. In fact, there are certain viewpoints that hardly can cause
> > > anything but regurgitation in a sane human being. On the hand, no one
> can
> > > denied anyone a right to express their opinions.
> > >
> > > Cos
> > >
> > > On Mon, Jul 06, 2015 at 12:10PM, Pierre Smits wrote:
> > >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> > >> statement of being disgusted by the viewpoint of others on the
> matter. I
> > >> hope you recover from it soon.
> > >>
> > >> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej 
> wrote:
> > >>
> > >>> On 04.07.2015 18:34, Pierre Smits wrote:
> > >>>> Having done a cursory review of the incubator reports to the board
> for
> > >>>> this year (January till May/June 2015), I found that only the SAMOA
> > >>>> podling reported working on a project set of bylaws, which without
> > >>>> knowing details could encompass and/or incorporate the code of
> conduct.
> > >>> I find myself disgusted by this widespread assumption that each
> project
> > >>> needs its own bylaws. WTF for? Are not ASF policies and practices
> enough
> > >>> for everyone? What sort of bylaws could you possibly invent that are
> > >>> both a useful extension of these policies and practices /and/ are not
> > >>> applicable to other projects?
> > >>>
> > >>> Per-project bylaws are just a tool for fragmenting the ASF
> community, in
> > >>> other words, they're a bad idea; paper-shuffling at its most useless.
> > >>>
> > >>> -- Brane
> > >>>
> >
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Konstantin Boudnik]

Hopefully you don't mind me helping with a colorful euphemisms here.
In the words of immortal Tao De Jing

 When government is lazy and informal
 The people are kind and honest;
 When government is efficient and severe
 The people are discontented and deceitful.

Cos

On Tue, Jul 07, 2015 at 03:11PM, Branko Čibej wrote:
> Pierre, I could find any number of euphemisms to say the same thing, but
> I prefer to say what I mean and not beat about the bush.
> 
> To give you an idea where my disgust comes from: Every project here that
> I know of that has bylaws about decision-making has some kind of
> fundamental problem and constant tensions in the community. Now some
> people may think that extra rules serve to keep problems in check, but
> IMO they just make things worse.
> 
> -- Brane
> 
> 
> On 06.07.2015 23:40, Konstantin Boudnik wrote:
> > That's called 'difference of opinions'. Nobody is entitled to like others'
> > viewpoints. In fact, there are certain viewpoints that hardly can cause
> > anything but regurgitation in a sane human being. On the hand, no one can
> > denied anyone a right to express their opinions.
> >
> > Cos
> >
> > On Mon, Jul 06, 2015 at 12:10PM, Pierre Smits wrote:
> >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> >> statement of being disgusted by the viewpoint of others on the matter. I
> >> hope you recover from it soon.
> >>
> >> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
> >>
> >>> On 04.07.2015 18:34, Pierre Smits wrote:
> >>>> Having done a cursory review of the incubator reports to the board for
> >>>> this year (January till May/June 2015), I found that only the SAMOA
> >>>> podling reported working on a project set of bylaws, which without
> >>>> knowing details could encompass and/or incorporate the code of conduct.
> >>> I find myself disgusted by this widespread assumption that each project
> >>> needs its own bylaws. WTF for? Are not ASF policies and practices enough
> >>> for everyone? What sort of bylaws could you possibly invent that are
> >>> both a useful extension of these policies and practices /and/ are not
> >>> applicable to other projects?
> >>>
> >>> Per-project bylaws are just a tool for fragmenting the ASF community, in
> >>> other words, they're a bad idea; paper-shuffling at its most useless.
> >>>
> >>> -- Brane
> >>>
> 

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Branko Čibej]

Pierre, I could find any number of euphemisms to say the same thing, but
I prefer to say what I mean and not beat about the bush.

To give you an idea where my disgust comes from: Every project here that
I know of that has bylaws about decision-making has some kind of
fundamental problem and constant tensions in the community. Now some
people may think that extra rules serve to keep problems in check, but
IMO they just make things worse.

-- Brane


On 06.07.2015 23:40, Konstantin Boudnik wrote:
> That's called 'difference of opinions'. Nobody is entitled to like others'
> viewpoints. In fact, there are certain viewpoints that hardly can cause
> anything but regurgitation in a sane human being. On the hand, no one can
> denied anyone a right to express their opinions.
>
> Cos
>
> On Mon, Jul 06, 2015 at 12:10PM, Pierre Smits wrote:
>> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
>> statement of being disgusted by the viewpoint of others on the matter. I
>> hope you recover from it soon.
>>
>> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
>>
>>> On 04.07.2015 18:34, Pierre Smits wrote:
>>>> Having done a cursory review of the incubator reports to the board for
>>>> this year (January till May/June 2015), I found that only the SAMOA
>>>> podling reported working on a project set of bylaws, which without
>>>> knowing details could encompass and/or incorporate the code of conduct.
>>> I find myself disgusted by this widespread assumption that each project
>>> needs its own bylaws. WTF for? Are not ASF policies and practices enough
>>> for everyone? What sort of bylaws could you possibly invent that are
>>> both a useful extension of these policies and practices /and/ are not
>>> applicable to other projects?
>>>
>>> Per-project bylaws are just a tool for fragmenting the ASF community, in
>>> other words, they're a bad idea; paper-shuffling at its most useless.
>>>
>>> -- Brane
>>>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Summarization != representation, Ross. I have faith that you'll be better
at summarising than any of the summarisation tools available.

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 Mon, Jul 6, 2015 at 9:31 PM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> Huh? How am I able to represent your view as well as you can?
>
> If you want me to restate *my* view I can do that by quoting my own view I
> will quote my summary from earlier in this thread: "In the absence of
> [project] bye-laws the defaults apply. "
>
> -Original Message-
> From: Pierre Smits [mailto:pierre.sm...@gmail.com]
> Sent: Monday, July 6, 2015 11:09 AM
> To: dev@community.apache.org
> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> of Better specifying)
>
> I am confident, Ross, that you are equally capable of doing that. So why
> don't you give it a go?
>
> 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 Mon, Jul 6, 2015 at 8:53 PM, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com> wrote:
>
> > So can you summarize what you are saying.
> >
> > Sent from Surface
> >
> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> > Sent: ?Monday?, ?July? ?6?, ?2015 ?10?:?47? ?AM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> >
> > Hi Konstantin,
> >
> > No, I am not saying that, neither explicitly nor effectively. Thus no,
> > not a correct representation of the point of discussion. Maybe you got
> > that impression (regarding blanket bylaws, or projects going off the
> > handle) by reading the postings of others.
> >
> > Best regards,
> >
> > Pierre
> >
> > Op maandag 6 juli 2015 heeft Konstantin Boudnik  het
> > volgende geschreven:
> >
> > > Let me see if I read you right, Pierre. Effectively, you're saying
> > > that imposing a blanket bylaws system should help to prevent some
> > > rare cases
> > of
> > > established projects going off the handle? Is this a correct
> > > representation of the point of this discussion?
> > >
> > > I am not as eloquent as you're in painting the picture of the
> > > law-less land, thus please accept my apologies in advance if I came
> > > to the wrong conclusions.
> > >
> > > With best regards,
> > >   Cos
> > >
> > > On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > > > Like expressed earlier, that loosely way of interpreting ASF
> > > > guidelines
> > > has
> > > > led to the situation that the board charges newly established
> > > > projects
> > to
> > > > define its bylaws. Charges that are then disregarded by the
> > > > project and
> > > not
> > > > followed up on by the board and or the appointed VP of the project.
> > > >
> > > > It is such that makes the determination of 'doing the right thing,
> > doing
> > > it
> > > > the right way' less credible in stead of more. The show flake
> > > > falling
> > > down
> > > > at the top of the mountain creates the avalanche in the valley.
> > > >
> > > > 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 Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> > > bdelacre...@apache.org >
> > > > wrote:
> > > >
> > > > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits <
> > pierre.sm...@gmail.com
> > > >
> > > > > wrote:
> > > > > > ...The latest posting by Jan proves the point of the necessity
> > > > > > of
> > > good
> > > > > > per-project bylaws when it comes to deviating from the generic
> > > guidelines
> > > > > > of the ASF...
> > > > >
> > > > > But as others have said, the best is to stick to those
> > > > > guidelines and use the default bylaws, unless it's absolutely
> > > > > necessary to do things differently.
> > > > >
> > > > > -Bertrand
> > > > >
> > >
> >
> >
> > --
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
>

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

Huh? How am I able to represent your view as well as you can?

If you want me to restate *my* view I can do that by quoting my own view I will 
quote my summary from earlier in this thread: "In the absence of [project] 
bye-laws the defaults apply. "

-Original Message-
From: Pierre Smits [mailto:pierre.sm...@gmail.com] 
Sent: Monday, July 6, 2015 11:09 AM
To: dev@community.apache.org
Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of 
Better specifying)

I am confident, Ross, that you are equally capable of doing that. So why don't 
you give it a go?

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 Mon, Jul 6, 2015 at 8:53 PM, Ross Gardler (MS OPEN TECH) < 
ross.gard...@microsoft.com> wrote:

> So can you summarize what you are saying.
>
> Sent from Surface
>
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ?Monday?, ?July? ?6?, ?2015 ?10?:?47? ?AM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
>
> Hi Konstantin,
>
> No, I am not saying that, neither explicitly nor effectively. Thus no, 
> not a correct representation of the point of discussion. Maybe you got 
> that impression (regarding blanket bylaws, or projects going off the 
> handle) by reading the postings of others.
>
> Best regards,
>
> Pierre
>
> Op maandag 6 juli 2015 heeft Konstantin Boudnik  het 
> volgende geschreven:
>
> > Let me see if I read you right, Pierre. Effectively, you're saying 
> > that imposing a blanket bylaws system should help to prevent some 
> > rare cases
> of
> > established projects going off the handle? Is this a correct 
> > representation of the point of this discussion?
> >
> > I am not as eloquent as you're in painting the picture of the 
> > law-less land, thus please accept my apologies in advance if I came 
> > to the wrong conclusions.
> >
> > With best regards,
> >   Cos
> >
> > On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > > Like expressed earlier, that loosely way of interpreting ASF 
> > > guidelines
> > has
> > > led to the situation that the board charges newly established 
> > > projects
> to
> > > define its bylaws. Charges that are then disregarded by the 
> > > project and
> > not
> > > followed up on by the board and or the appointed VP of the project.
> > >
> > > It is such that makes the determination of 'doing the right thing,
> doing
> > it
> > > the right way' less credible in stead of more. The show flake 
> > > falling
> > down
> > > at the top of the mountain creates the avalanche in the valley.
> > >
> > > 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 Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> > bdelacre...@apache.org >
> > > wrote:
> > >
> > > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits <
> pierre.sm...@gmail.com
> > >
> > > > wrote:
> > > > > ...The latest posting by Jan proves the point of the necessity 
> > > > > of
> > good
> > > > > per-project bylaws when it comes to deviating from the generic
> > guidelines
> > > > > of the ASF...
> > > >
> > > > But as others have said, the best is to stick to those 
> > > > guidelines and use the default bylaws, unless it's absolutely 
> > > > necessary to do things differently.
> > > >
> > > > -Bertrand
> > > >
> >
>
>
> --
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Konstantin Boudnik]

That's called 'difference of opinions'. Nobody is entitled to like others'
viewpoints. In fact, there are certain viewpoints that hardly can cause
anything but regurgitation in a sane human being. On the hand, no one can
denied anyone a right to express their opinions.

Cos

On Mon, Jul 06, 2015 at 12:10PM, Pierre Smits wrote:
> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> statement of being disgusted by the viewpoint of others on the matter. I
> hope you recover from it soon.
> 
> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
> 
> > On 04.07.2015 18:34, Pierre Smits wrote:
> > > Having done a cursory review of the incubator reports to the board for
> > > this year (January till May/June 2015), I found that only the SAMOA
> > > podling reported working on a project set of bylaws, which without
> > > knowing details could encompass and/or incorporate the code of conduct.
> >
> > I find myself disgusted by this widespread assumption that each project
> > needs its own bylaws. WTF for? Are not ASF policies and practices enough
> > for everyone? What sort of bylaws could you possibly invent that are
> > both a useful extension of these policies and practices /and/ are not
> > applicable to other projects?
> >
> > Per-project bylaws are just a tool for fragmenting the ASF community, in
> > other words, they're a bad idea; paper-shuffling at its most useless.
> >
> > -- Brane
> >

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

I am confident, Ross, that you are equally capable of doing that. So why
don't you give it a go?

Best regards,

Pierre Smits

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

On Mon, Jul 6, 2015 at 8:53 PM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> So can you summarize what you are saying.
>
> Sent from Surface
>
> From: Pierre Smits
> Sent: ?Monday?, ?July? ?6?, ?2015 ?10?:?47? ?AM
> To: dev@community.apache.org
>
> Hi Konstantin,
>
> No, I am not saying that, neither explicitly nor effectively. Thus no, not
> a correct representation of the point of discussion. Maybe you got that
> impression (regarding blanket bylaws, or projects going off the handle) by
> reading the postings of others.
>
> Best regards,
>
> Pierre
>
> Op maandag 6 juli 2015 heeft Konstantin Boudnik  het
> volgende geschreven:
>
> > Let me see if I read you right, Pierre. Effectively, you're saying that
> > imposing a blanket bylaws system should help to prevent some rare cases
> of
> > established projects going off the handle? Is this a correct
> > representation of
> > the point of this discussion?
> >
> > I am not as eloquent as you're in painting the picture of the law-less
> > land,
> > thus please accept my apologies in advance if I came to the wrong
> > conclusions.
> >
> > With best regards,
> >   Cos
> >
> > On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > > Like expressed earlier, that loosely way of interpreting ASF guidelines
> > has
> > > led to the situation that the board charges newly established projects
> to
> > > define its bylaws. Charges that are then disregarded by the project and
> > not
> > > followed up on by the board and or the appointed VP of the project.
> > >
> > > It is such that makes the determination of 'doing the right thing,
> doing
> > it
> > > the right way' less credible in stead of more. The show flake falling
> > down
> > > at the top of the mountain creates the avalanche in the valley.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM *
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> > bdelacre...@apache.org >
> > > wrote:
> > >
> > > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits <
> pierre.sm...@gmail.com
> > >
> > > > wrote:
> > > > > ...The latest posting by Jan proves the point of the necessity of
> > good
> > > > > per-project bylaws when it comes to deviating from the generic
> > guidelines
> > > > > of the ASF...
> > > >
> > > > But as others have said, the best is to stick to those guidelines and
> > > > use the default bylaws, unless it's absolutely necessary to do things
> > > > differently.
> > > >
> > > > -Bertrand
> > > >
> >
>
>
> --
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

No worries, Konstantin. I won't hold that against you.

Best regards,

Pierre Smits

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

On Mon, Jul 6, 2015 at 8:57 PM, Konstantin Boudnik  wrote:

> Just to point to the source of my confusiony. My impression came from this
> part:
>
> > > > Like expressed earlier, that loosely way of interpreting ASF
> guidelines has
> > > > led to the situation that the board charges newly established
> projects to
> > > > define its bylaws. Charges that are then disregarded by the project
> and not
> > > > followed up on by the board and or the appointed VP of the project.
>
> The subsequent colorful passage about the snowflake led me to believe that
> you're indeed found a way to prevent said snowflake from landing on the
> top of
> the mountain. Looks like my interpretation of the meaning of it was quite
> suboptimal. Thanks for the explanation, Pierre.
>
> Cos
>
> On Mon, Jul 06, 2015 at 08:47PM, Pierre Smits wrote:
> > Hi Konstantin,
> >
> > No, I am not saying that, neither explicitly nor effectively. Thus no,
> not
> > a correct representation of the point of discussion. Maybe you got that
> > impression (regarding blanket bylaws, or projects going off the handle)
> by
> > reading the postings of others.
> >
> > Best regards,
> >
> > Pierre
> >
> > Op maandag 6 juli 2015 heeft Konstantin Boudnik  het
> > volgende geschreven:
> >
> > > Let me see if I read you right, Pierre. Effectively, you're saying that
> > > imposing a blanket bylaws system should help to prevent some rare
> cases of
> > > established projects going off the handle? Is this a correct
> > > representation of
> > > the point of this discussion?
> > >
> > > I am not as eloquent as you're in painting the picture of the law-less
> > > land,
> > > thus please accept my apologies in advance if I came to the wrong
> > > conclusions.
> > >
> > > With best regards,
> > >   Cos
> > >
> > > On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > > > Like expressed earlier, that loosely way of interpreting ASF
> guidelines has
> > > > led to the situation that the board charges newly established
> projects to
> > > > define its bylaws. Charges that are then disregarded by the project
> and not
> > > > followed up on by the board and or the appointed VP of the project.
> > > >
> > > > It is such that makes the determination of 'doing the right thing,
> doing
> > > it
> > > > the right way' less credible in stead of more. The show flake falling
> > > down
> > > > at the top of the mountain creates the avalanche in the valley.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > *ORRTIZ.COM *
> > > > Services & Solutions for Cloud-
> > > > Based Manufacturing, Professional
> > > > Services and Retail & Trade
> > > > http://www.orrtiz.com
> > > >
> > > > On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> > > bdelacre...@apache.org >
> > > > wrote:
> > > >
> > > > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits <
> pierre.sm...@gmail.com
> > > >
> > > > > wrote:
> > > > > > ...The latest posting by Jan proves the point of the necessity of
> > > good
> > > > > > per-project bylaws when it comes to deviating from the generic
> > > guidelines
> > > > > > of the ASF...
> > > > >
> > > > > But as others have said, the best is to stick to those guidelines
> and
> > > > > use the default bylaws, unless it's absolutely necessary to do
> things
> > > > > differently.
> > > > >
> > > > > -Bertrand
> > > > >
> > >
> >
> >
> > --
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Konstantin Boudnik]

Just to point to the source of my confusiony. My impression came from this part:

> > > Like expressed earlier, that loosely way of interpreting ASF guidelines 
> > > has
> > > led to the situation that the board charges newly established projects to
> > > define its bylaws. Charges that are then disregarded by the project and 
> > > not
> > > followed up on by the board and or the appointed VP of the project.

The subsequent colorful passage about the snowflake led me to believe that
you're indeed found a way to prevent said snowflake from landing on the top of
the mountain. Looks like my interpretation of the meaning of it was quite
suboptimal. Thanks for the explanation, Pierre.

Cos

On Mon, Jul 06, 2015 at 08:47PM, Pierre Smits wrote:
> Hi Konstantin,
> 
> No, I am not saying that, neither explicitly nor effectively. Thus no, not
> a correct representation of the point of discussion. Maybe you got that
> impression (regarding blanket bylaws, or projects going off the handle) by
> reading the postings of others.
> 
> Best regards,
> 
> Pierre
> 
> Op maandag 6 juli 2015 heeft Konstantin Boudnik  het
> volgende geschreven:
> 
> > Let me see if I read you right, Pierre. Effectively, you're saying that
> > imposing a blanket bylaws system should help to prevent some rare cases of
> > established projects going off the handle? Is this a correct
> > representation of
> > the point of this discussion?
> >
> > I am not as eloquent as you're in painting the picture of the law-less
> > land,
> > thus please accept my apologies in advance if I came to the wrong
> > conclusions.
> >
> > With best regards,
> >   Cos
> >
> > On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > > Like expressed earlier, that loosely way of interpreting ASF guidelines 
> > > has
> > > led to the situation that the board charges newly established projects to
> > > define its bylaws. Charges that are then disregarded by the project and 
> > > not
> > > followed up on by the board and or the appointed VP of the project.
> > >
> > > It is such that makes the determination of 'doing the right thing, doing
> > it
> > > the right way' less credible in stead of more. The show flake falling
> > down
> > > at the top of the mountain creates the avalanche in the valley.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM *
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> > bdelacre...@apache.org >
> > > wrote:
> > >
> > > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits  > >
> > > > wrote:
> > > > > ...The latest posting by Jan proves the point of the necessity of
> > good
> > > > > per-project bylaws when it comes to deviating from the generic
> > guidelines
> > > > > of the ASF...
> > > >
> > > > But as others have said, the best is to stick to those guidelines and
> > > > use the default bylaws, unless it's absolutely necessary to do things
> > > > differently.
> > > >
> > > > -Bertrand
> > > >
> >
> 
> 
> -- 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com


signature.asc
Description: Digital signature

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

So can you summarize what you are saying.

Sent from Surface

From: Pierre Smits
Sent: ?Monday?, ?July? ?6?, ?2015 ?10?:?47? ?AM
To: dev@community.apache.org

Hi Konstantin,

No, I am not saying that, neither explicitly nor effectively. Thus no, not
a correct representation of the point of discussion. Maybe you got that
impression (regarding blanket bylaws, or projects going off the handle) by
reading the postings of others.

Best regards,

Pierre

Op maandag 6 juli 2015 heeft Konstantin Boudnik  het
volgende geschreven:

> Let me see if I read you right, Pierre. Effectively, you're saying that
> imposing a blanket bylaws system should help to prevent some rare cases of
> established projects going off the handle? Is this a correct
> representation of
> the point of this discussion?
>
> I am not as eloquent as you're in painting the picture of the law-less
> land,
> thus please accept my apologies in advance if I came to the wrong
> conclusions.
>
> With best regards,
>   Cos
>
> On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > Like expressed earlier, that loosely way of interpreting ASF guidelines
> has
> > led to the situation that the board charges newly established projects to
> > define its bylaws. Charges that are then disregarded by the project and
> not
> > followed up on by the board and or the appointed VP of the project.
> >
> > It is such that makes the determination of 'doing the right thing, doing
> it
> > the right way' less credible in stead of more. The show flake falling
> down
> > at the top of the mountain creates the avalanche in the valley.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> bdelacre...@apache.org >
> > wrote:
> >
> > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits  >
> > > wrote:
> > > > ...The latest posting by Jan proves the point of the necessity of
> good
> > > > per-project bylaws when it comes to deviating from the generic
> guidelines
> > > > of the ASF...
> > >
> > > But as others have said, the best is to stick to those guidelines and
> > > use the default bylaws, unless it's absolutely necessary to do things
> > > differently.
> > >
> > > -Bertrand
> > >
>


--
Pierre Smits

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

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Hi Konstantin,

No, I am not saying that, neither explicitly nor effectively. Thus no, not
a correct representation of the point of discussion. Maybe you got that
impression (regarding blanket bylaws, or projects going off the handle) by
reading the postings of others.

Best regards,

Pierre

Op maandag 6 juli 2015 heeft Konstantin Boudnik  het
volgende geschreven:

> Let me see if I read you right, Pierre. Effectively, you're saying that
> imposing a blanket bylaws system should help to prevent some rare cases of
> established projects going off the handle? Is this a correct
> representation of
> the point of this discussion?
>
> I am not as eloquent as you're in painting the picture of the law-less
> land,
> thus please accept my apologies in advance if I came to the wrong
> conclusions.
>
> With best regards,
>   Cos
>
> On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> > Like expressed earlier, that loosely way of interpreting ASF guidelines
> has
> > led to the situation that the board charges newly established projects to
> > define its bylaws. Charges that are then disregarded by the project and
> not
> > followed up on by the board and or the appointed VP of the project.
> >
> > It is such that makes the determination of 'doing the right thing, doing
> it
> > the right way' less credible in stead of more. The show flake falling
> down
> > at the top of the mountain creates the avalanche in the valley.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> bdelacre...@apache.org >
> > wrote:
> >
> > > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits  >
> > > wrote:
> > > > ...The latest posting by Jan proves the point of the necessity of
> good
> > > > per-project bylaws when it comes to deviating from the generic
> guidelines
> > > > of the ASF...
> > >
> > > But as others have said, the best is to stick to those guidelines and
> > > use the default bylaws, unless it's absolutely necessary to do things
> > > differently.
> > >
> > > -Bertrand
> > >
>


-- 
Pierre Smits

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

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Konstantin Boudnik]

Let me see if I read you right, Pierre. Effectively, you're saying that
imposing a blanket bylaws system should help to prevent some rare cases of
established projects going off the handle? Is this a correct representation of
the point of this discussion? 

I am not as eloquent as you're in painting the picture of the law-less land,
thus please accept my apologies in advance if I came to the wrong conclusions.

With best regards,
  Cos

On Mon, Jul 06, 2015 at 01:34PM, Pierre Smits wrote:
> Like expressed earlier, that loosely way of interpreting ASF guidelines has
> led to the situation that the board charges newly established projects to
> define its bylaws. Charges that are then disregarded by the project and not
> followed up on by the board and or the appointed VP of the project.
> 
> It is such that makes the determination of 'doing the right thing, doing it
> the right way' less credible in stead of more. The show flake falling down
> at the top of the mountain creates the avalanche in the valley.
> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz 
> wrote:
> 
> > On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits 
> > wrote:
> > > ...The latest posting by Jan proves the point of the necessity of good
> > > per-project bylaws when it comes to deviating from the generic guidelines
> > > of the ASF...
> >
> > But as others have said, the best is to stick to those guidelines and
> > use the default bylaws, unless it's absolutely necessary to do things
> > differently.
> >
> > -Bertrand
> >


signature.asc
Description: Digital signature

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[zinhtut aung]

On 5 Jul 2015 00:34, "Pierre Smits"  wrote:

> >> Having such an official ASF policy without the executing office policing
> >> it, without podlings being required to accept and instill it in their
> >> bylaws before graduation and allowing existing projects not to
> incorporate
> >> it makes it nothing more than a hollow statement,
> >>
> > Being part of IPMC, I thought it was part of the incubator to make sure
> that
> > exactly this happened.
>
> Having done a cursory review of the incubator reports to the board for this
> year (January till May/June 2015), I found that only the SAMOA podling
> reported working on a project set of bylaws, which without knowing details
> could encompass and/or incorporate the code of conduct.
> None of the other podlings reported about that. Having looked also at the
> board reports for January up to May 2015 I found that podlings graduating
> to TLP were either tasked by the board to establish a set of bylaws or not.
>
> This tells me that acceptance/incorporation of the code of conduct of the
> ASF by the podlings is not a requirement.
> It might also mean - given the code of conduct as it is today - that IPMC
> members (as mentors) are either not fully aware that
> acceptance/incorporation is part of incubation process, or that they
> consider it optional.
>
> What I also observed from the board reports (minutes) from Jan till May is
> that while graduating podlings (as part of their establisment as a TLP)
> where tasked by the board to create a set of bylaws, that up to now those
> projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
> Zest) don't reference anything about a set of bylaws.
> And one graduating (Apache Samza) was not tasked with creating a set of
> bylaws at all by the board.
>
> It seems to me that this viewpoint of flexibility for projects has led to
> various approaches applied during the incubation phase. Making it harder to
> tell a unified story to the outside world...
> The Code of Conduct affects more the community aspect while being under the
> umbrella of the ASF than the code aspect. The Code of Conduct and the
> Apache Way (community over code) is foremost about how the contributors
> interact. About how to do just to all contributors, not how to favour a
> few
> The bylaws of a project should reflect how that is done, meaning defining
> the rules regarding procedural matters (which culminates about how the
> project deals with onboarding and ofboarding of contributors visavis
> privileges - commit privileges, PMC, PMC Chair).
>
> And shouldn't the VP of the project report back to the board, in the
> projects regular report, about the progress? And shouldn't the board keep
> track of what it has task the project to do, and/or check that a project's
> bylaws doesn't conflict with the Code of Conduct or the 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 Fri, Jul 3, 2015 at 12:10 PM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
> > Hi,
> >
> > As there was no opposition I have modified the first few paragraphs of
> > http://www.apache.org/foundation/policies/conduct.html as below.
> >
> > -Bertrand
> >
> > On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
> >  wrote:
> > > *** reworked code of conduct intro section ***
> > > This code of conduct applies to all spaces managed by the Apache
> > > Software Foundation, including IRC, all public and private mailing
> > > lists, issue trackers, wikis, blogs, Twitter, and any other
> > > communication channel used by our communities. A code of conduct which
> > > is specific to in-person events (ie., conferences) is codified in the
> > > published ASF anti-harassment policy.
> > >
> > > We expect this code of conduct to be honored by everyone who
> > > participates in the Apache community formally or informally, or claims
> > > any affiliation with the Foundation, in any Foundation-related
> > > activities and especially when representing the ASF, in any role.
> > >
> > > This code is not exhaustive or complete(unchanged from here on)
> > > *** reworked code of conduct intro section ***
> >
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[zinhtut aung]

https://plus.google.com/+GoogleArtProject
On 6 Jul 2015 23:45, "Pierre Smits"  wrote:

> Actually, Martin, I read that too a while ago, and I can't regard it as
> anything else but just a viewpoint expressed by someone who is reacting to
> a posting of someone else
>
> Such an expression neither makes it a policy of the ASF, nor justifies why
> the board, when voting on a podling wishing graduating to TLP, keep
> something going on that is considered by some as disgusting or as adding no
> value by others.
>
> If it were as simple as some regard this aspect of doing the right thing,
> then a simple vote would solve it (for the time being) and both board and
> Incubator could adjust their procedures and instructions to all
> accordingly.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Jul 6, 2015 at 5:52 PM, Marvin Humphrey 
> wrote:
>
> > On Mon, Jul 6, 2015 at 12:51 AM, Branko Čibej  wrote:
> >
> > > I find myself disgusted by this widespread assumption that each project
> > > needs its own bylaws. WTF for? Are not ASF policies and practices
> enough
> > > for everyone? What sort of bylaws could you possibly invent that are
> > > both a useful extension of these policies and practices /and/ are not
> > > applicable to other projects?
> >
> > Here's the historical rationale for per-project bylaws, which explains
> > why it's in the TLP resolution template:
> >
> >   http://s.apache.org/why-project-bylaws
> >
> >   Apache doesn't have a single set of project bylaws/guidelines because
> >   we want projects to be self-governing...
> >
> > Speaking with the benefit of hindsight not available to those who
> > blazed the trail, my assessment is that while the idea of making
> > projects think about governance is laudable, drafting bylaws is too
> > difficult a problem to be tackled by each new TLP.  Minute drafting
> > errors cause large problems.
> >
> > Marvin Humphrey
> >
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Actually, Martin, I read that too a while ago, and I can't regard it as
anything else but just a viewpoint expressed by someone who is reacting to
a posting of someone else

Such an expression neither makes it a policy of the ASF, nor justifies why
the board, when voting on a podling wishing graduating to TLP, keep
something going on that is considered by some as disgusting or as adding no
value by others.

If it were as simple as some regard this aspect of doing the right thing,
then a simple vote would solve it (for the time being) and both board and
Incubator could adjust their procedures and instructions to all accordingly.

Best regards,

Pierre Smits

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

On Mon, Jul 6, 2015 at 5:52 PM, Marvin Humphrey 
wrote:

> On Mon, Jul 6, 2015 at 12:51 AM, Branko Čibej  wrote:
>
> > I find myself disgusted by this widespread assumption that each project
> > needs its own bylaws. WTF for? Are not ASF policies and practices enough
> > for everyone? What sort of bylaws could you possibly invent that are
> > both a useful extension of these policies and practices /and/ are not
> > applicable to other projects?
>
> Here's the historical rationale for per-project bylaws, which explains
> why it's in the TLP resolution template:
>
>   http://s.apache.org/why-project-bylaws
>
>   Apache doesn't have a single set of project bylaws/guidelines because
>   we want projects to be self-governing...
>
> Speaking with the benefit of hindsight not available to those who
> blazed the trail, my assessment is that while the idea of making
> projects think about governance is laudable, drafting bylaws is too
> difficult a problem to be tackled by each new TLP.  Minute drafting
> errors cause large problems.
>
> Marvin Humphrey
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[zinhtut aung]

On 6 Jul 2015 20:26, "Benson Margulies"  wrote:
>
> This thread started with a discussion of the CoC. The premise of the
> thread was this: that counter-CoC behavior might emerge on a project,
> and that the project might tolerate, or even celebrate, that behavior,
> for lack of an explicit bylaw explicitly adopting the CoC.
>
> This premise is wrong. The CoC applies to everyone at Apache, inside
> the established projects or outside (such as on this mailing list). If
> any reader of this mailing list observes behavior contrary to the CoC,
> that member should address it, escalating to the board if needed.
>
> If folks want to continue to exchange arguments about the value, or
> lack thereof, of per-project bylaws on other accounts, I wish they'd
> change the subject line.

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Marvin Humphrey]

On Mon, Jul 6, 2015 at 12:51 AM, Branko Čibej  wrote:

> I find myself disgusted by this widespread assumption that each project
> needs its own bylaws. WTF for? Are not ASF policies and practices enough
> for everyone? What sort of bylaws could you possibly invent that are
> both a useful extension of these policies and practices /and/ are not
> applicable to other projects?

Here's the historical rationale for per-project bylaws, which explains
why it's in the TLP resolution template:

  http://s.apache.org/why-project-bylaws

  Apache doesn't have a single set of project bylaws/guidelines because
  we want projects to be self-governing...

Speaking with the benefit of hindsight not available to those who
blazed the trail, my assessment is that while the idea of making
projects think about governance is laudable, drafting bylaws is too
difficult a problem to be tackled by each new TLP.  Minute drafting
errors cause large problems.

Marvin Humphrey

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Benson Margulies]

This thread started with a discussion of the CoC. The premise of the
thread was this: that counter-CoC behavior might emerge on a project,
and that the project might tolerate, or even celebrate, that behavior,
for lack of an explicit bylaw explicitly adopting the CoC.

This premise is wrong. The CoC applies to everyone at Apache, inside
the established projects or outside (such as on this mailing list). If
any reader of this mailing list observes behavior contrary to the CoC,
that member should address it, escalating to the board if needed.

If folks want to continue to exchange arguments about the value, or
lack thereof, of per-project bylaws on other accounts, I wish they'd
change the subject line.

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[jan i]

On Monday, July 6, 2015, sebb  wrote:

> On 6 July 2015 at 10:24, jan i > wrote:
> > On 6 July 2015 at 11:10, Pierre Smits  > wrote:
> >
> >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> >> statement of being disgusted by the viewpoint of others on the matter. I
> >> hope you recover from it soon.
> >>
> >
> > Having been (and still be) in a project that have strong bylaws, limiting
> > voting etc,
> > I know what a PITA project bylaws can be.
> >
> > We fought for about 6 month to get the bylaws changed, to something there
> > was
> > total consensus about. The problem was that the bylaws could only be
> changed
> > with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the PMC
> no
> > longer
> > are active.
>
> As I recall, the main problem was that the local project bylaws had
> been badly drafted, and were not clear, so needed to be changed.


the bylaws was very clear and understandable but drafted in a time where
LABS was a active project.

>
>
> > Bylaws can in some special cases help a project, but really should not be
> > necesary. If
> > our bylaws and policies are unprecise we should do something centrally
> and
> > not remedy
> > this problem in 200 projects.
>
> Indeed. Had the local project bylaws not existed, I suspect there
> would have been no problem in the case to which Jan refers.


Correct actually LABS is a good example of a project where the bylaws are
not needed.

rgds
jan i

>
> > rgds
> > jan I.
> >
> >
> >>
> >> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  > wrote:
> >>
> >> > On 04.07.2015 18:34, Pierre Smits wrote:
> >> > > Having done a cursory review of the incubator reports to the board
> for
> >> > > this year (January till May/June 2015), I found that only the SAMOA
> >> > > podling reported working on a project set of bylaws, which without
> >> > > knowing details could encompass and/or incorporate the code of
> conduct.
> >> >
> >> > I find myself disgusted by this widespread assumption that each
> project
> >> > needs its own bylaws. WTF for? Are not ASF policies and practices
> enough
> >> > for everyone? What sort of bylaws could you possibly invent that are
> >> > both a useful extension of these policies and practices /and/ are not
> >> > applicable to other projects?
> >> >
> >> > Per-project bylaws are just a tool for fragmenting the ASF community,
> in
> >> > other words, they're a bad idea; paper-shuffling at its most useless.
> >> >
> >> > -- Brane
> >> >
> >>
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Or not! Some still believe that it is 'consensus' that is required for any
procedural issues and think their -1 vote vetoes a change. That applies not
only to on and off-boarding of new PMC Members and committers, but also to
other policy changes.

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 Mon, Jul 6, 2015 at 2:57 PM, sebb  wrote:

> On 6 July 2015 at 10:24, jan i  wrote:
> > On 6 July 2015 at 11:10, Pierre Smits  wrote:
> >
> >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> >> statement of being disgusted by the viewpoint of others on the matter. I
> >> hope you recover from it soon.
> >>
> >
> > Having been (and still be) in a project that have strong bylaws, limiting
> > voting etc,
> > I know what a PITA project bylaws can be.
> >
> > We fought for about 6 month to get the bylaws changed, to something there
> > was
> > total consensus about. The problem was that the bylaws could only be
> changed
> > with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the PMC
> no
> > longer
> > are active.
>
> As I recall, the main problem was that the local project bylaws had
> been badly drafted, and were not clear, so needed to be changed.
>
>
> > Bylaws can in some special cases help a project, but really should not be
> > necesary. If
> > our bylaws and policies are unprecise we should do something centrally
> and
> > not remedy
> > this problem in 200 projects.
>
> Indeed. Had the local project bylaws not existed, I suspect there
> would have been no problem in the case to which Jan refers.
>
> > rgds
> > jan I.
> >
> >
> >>
> >> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
> >>
> >> > On 04.07.2015 18:34, Pierre Smits wrote:
> >> > > Having done a cursory review of the incubator reports to the board
> for
> >> > > this year (January till May/June 2015), I found that only the SAMOA
> >> > > podling reported working on a project set of bylaws, which without
> >> > > knowing details could encompass and/or incorporate the code of
> conduct.
> >> >
> >> > I find myself disgusted by this widespread assumption that each
> project
> >> > needs its own bylaws. WTF for? Are not ASF policies and practices
> enough
> >> > for everyone? What sort of bylaws could you possibly invent that are
> >> > both a useful extension of these policies and practices /and/ are not
> >> > applicable to other projects?
> >> >
> >> > Per-project bylaws are just a tool for fragmenting the ASF community,
> in
> >> > other words, they're a bad idea; paper-shuffling at its most useless.
> >> >
> >> > -- Brane
> >> >
> >>
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[sebb]

On 6 July 2015 at 10:24, jan i  wrote:
> On 6 July 2015 at 11:10, Pierre Smits  wrote:
>
>> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
>> statement of being disgusted by the viewpoint of others on the matter. I
>> hope you recover from it soon.
>>
>
> Having been (and still be) in a project that have strong bylaws, limiting
> voting etc,
> I know what a PITA project bylaws can be.
>
> We fought for about 6 month to get the bylaws changed, to something there
> was
> total consensus about. The problem was that the bylaws could only be changed
> with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the PMC no
> longer
> are active.

As I recall, the main problem was that the local project bylaws had
been badly drafted, and were not clear, so needed to be changed.


> Bylaws can in some special cases help a project, but really should not be
> necesary. If
> our bylaws and policies are unprecise we should do something centrally and
> not remedy
> this problem in 200 projects.

Indeed. Had the local project bylaws not existed, I suspect there
would have been no problem in the case to which Jan refers.

> rgds
> jan I.
>
>
>>
>> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
>>
>> > On 04.07.2015 18:34, Pierre Smits wrote:
>> > > Having done a cursory review of the incubator reports to the board for
>> > > this year (January till May/June 2015), I found that only the SAMOA
>> > > podling reported working on a project set of bylaws, which without
>> > > knowing details could encompass and/or incorporate the code of conduct.
>> >
>> > I find myself disgusted by this widespread assumption that each project
>> > needs its own bylaws. WTF for? Are not ASF policies and practices enough
>> > for everyone? What sort of bylaws could you possibly invent that are
>> > both a useful extension of these policies and practices /and/ are not
>> > applicable to other projects?
>> >
>> > Per-project bylaws are just a tool for fragmenting the ASF community, in
>> > other words, they're a bad idea; paper-shuffling at its most useless.
>> >
>> > -- Brane
>> >
>>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

And you can read 'determination' as well as 'perception'.

Best regards,

Pierre Smits

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

On Mon, Jul 6, 2015 at 1:34 PM, Pierre Smits  wrote:

> Like expressed earlier, that loosely way of interpreting ASF guidelines
> has led to the situation that the board charges newly established projects
> to define its bylaws. Charges that are then disregarded by the project and
> not followed up on by the board and or the appointed VP of the project.
>
> It is such that makes the determination of 'doing the right thing, doing
> it the right way' less credible in stead of more. The show flake falling
> down at the top of the mountain creates the avalanche in the valley.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
>
>> On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits 
>> wrote:
>> > ...The latest posting by Jan proves the point of the necessity of good
>> > per-project bylaws when it comes to deviating from the generic
>> guidelines
>> > of the ASF...
>>
>> But as others have said, the best is to stick to those guidelines and
>> use the default bylaws, unless it's absolutely necessary to do things
>> differently.
>>
>> -Bertrand
>>
>
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Like expressed earlier, that loosely way of interpreting ASF guidelines has
led to the situation that the board charges newly established projects to
define its bylaws. Charges that are then disregarded by the project and not
followed up on by the board and or the appointed VP of the project.

It is such that makes the determination of 'doing the right thing, doing it
the right way' less credible in stead of more. The show flake falling down
at the top of the mountain creates the avalanche in the valley.

Best regards,

Pierre Smits

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

On Mon, Jul 6, 2015 at 1:25 PM, Bertrand Delacretaz 
wrote:

> On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits 
> wrote:
> > ...The latest posting by Jan proves the point of the necessity of good
> > per-project bylaws when it comes to deviating from the generic guidelines
> > of the ASF...
>
> But as others have said, the best is to stick to those guidelines and
> use the default bylaws, unless it's absolutely necessary to do things
> differently.
>
> -Bertrand
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Bertrand Delacretaz]

On Mon, Jul 6, 2015 at 11:38 AM, Pierre Smits  wrote:
> ...The latest posting by Jan proves the point of the necessity of good
> per-project bylaws when it comes to deviating from the generic guidelines
> of the ASF...

But as others have said, the best is to stick to those guidelines and
use the default bylaws, unless it's absolutely necessary to do things
differently.

-Bertrand

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

The latest posting by Jan proves the point of the necessity of good
per-project bylaws when it comes to deviating from the generic guidelines
of the ASF.

Bylaws define the parameters of how processes are be executed within a
project, when it comes to the procedural aspects. His example given,
regarding the lifetime employment of PMC members shows that a definitive
description of how onboarding and ofboarding of PMC Members takes place in
the project could have saved it a lot of time and trouble.

The incubation process is the right place to thing about these aspects as
mentors of can could provide the insights and experience in order to avoid
creating either bylaw elements that are either to vague to apply or to
complex to uphold that will lead to (unnecessary and avoidable) heated
discussions that hurt the project more than they do good.

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 Mon, Jul 6, 2015 at 12:24 PM, jan i  wrote:

> On 6 July 2015 at 11:10, Pierre Smits  wrote:
>
> > Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> > statement of being disgusted by the viewpoint of others on the matter. I
> > hope you recover from it soon.
> >
>
> Having been (and still be) in a project that have strong bylaws, limiting
> voting etc,
> I know what a PITA project bylaws can be.
>
> We fought for about 6 month to get the bylaws changed, to something there
> was
> total consensus about. The problem was that the bylaws could only be
> changed
> with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the PMC no
> longer
> are active.
>
> Bylaws can in some special cases help a project, but really should not be
> necesary. If
> our bylaws and policies are unprecise we should do something centrally and
> not remedy
> this problem in 200 projects.
>
> rgds
> jan I.
>
>
> >
> > 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
> >
> > > On 04.07.2015 18:34, Pierre Smits wrote:
> > > > Having done a cursory review of the incubator reports to the board
> for
> > > > this year (January till May/June 2015), I found that only the SAMOA
> > > > podling reported working on a project set of bylaws, which without
> > > > knowing details could encompass and/or incorporate the code of
> conduct.
> > >
> > > I find myself disgusted by this widespread assumption that each project
> > > needs its own bylaws. WTF for? Are not ASF policies and practices
> enough
> > > for everyone? What sort of bylaws could you possibly invent that are
> > > both a useful extension of these policies and practices /and/ are not
> > > applicable to other projects?
> > >
> > > Per-project bylaws are just a tool for fragmenting the ASF community,
> in
> > > other words, they're a bad idea; paper-shuffling at its most useless.
> > >
> > > -- Brane
> > >
> >
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[jan i]

On 6 July 2015 at 11:10, Pierre Smits  wrote:

> Thank you, Branko. I feel (somewhat) sorry for you, when I read your
> statement of being disgusted by the viewpoint of others on the matter. I
> hope you recover from it soon.
>

Having been (and still be) in a project that have strong bylaws, limiting
voting etc,
I know what a PITA project bylaws can be.

We fought for about 6 month to get the bylaws changed, to something there
was
total consensus about. The problem was that the bylaws could only be changed
with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the PMC no
longer
are active.

Bylaws can in some special cases help a project, but really should not be
necesary. If
our bylaws and policies are unprecise we should do something centrally and
not remedy
this problem in 200 projects.

rgds
jan I.


>
> 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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:
>
> > On 04.07.2015 18:34, Pierre Smits wrote:
> > > Having done a cursory review of the incubator reports to the board for
> > > this year (January till May/June 2015), I found that only the SAMOA
> > > podling reported working on a project set of bylaws, which without
> > > knowing details could encompass and/or incorporate the code of conduct.
> >
> > I find myself disgusted by this widespread assumption that each project
> > needs its own bylaws. WTF for? Are not ASF policies and practices enough
> > for everyone? What sort of bylaws could you possibly invent that are
> > both a useful extension of these policies and practices /and/ are not
> > applicable to other projects?
> >
> > Per-project bylaws are just a tool for fragmenting the ASF community, in
> > other words, they're a bad idea; paper-shuffling at its most useless.
> >
> > -- Brane
> >
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Thank you, Branko. I feel (somewhat) sorry for you, when I read your
statement of being disgusted by the viewpoint of others on the matter. I
hope you recover from it soon.

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 Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej  wrote:

> On 04.07.2015 18:34, Pierre Smits wrote:
> > Having done a cursory review of the incubator reports to the board for
> > this year (January till May/June 2015), I found that only the SAMOA
> > podling reported working on a project set of bylaws, which without
> > knowing details could encompass and/or incorporate the code of conduct.
>
> I find myself disgusted by this widespread assumption that each project
> needs its own bylaws. WTF for? Are not ASF policies and practices enough
> for everyone? What sort of bylaws could you possibly invent that are
> both a useful extension of these policies and practices /and/ are not
> applicable to other projects?
>
> Per-project bylaws are just a tool for fragmenting the ASF community, in
> other words, they're a bad idea; paper-shuffling at its most useless.
>
> -- Brane
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

I would say that the (hints of) examples presented, especially meaning
deviation of the general 'guideline' of a simple majority vote for
(procedural) aspects would be enough reason for any aspiring ASF project to
do just to all to have a set of bylaws.

Despite all the ASF pages to make its philosophies interpretable in only
one way, I hear/see a lot of variants of what is the Apache Way or the
Apache Code of Conduct from various - fellow - ASF politicians (pun
intended :-)).

It is bylaws that decrease the ambiguity instilled in the ASF pages,
ensuring that due process is or can be established, that every contributor
can expect rules to be applied equally to all. Guidelines, as some of the
esteemed Members of the ASF or participants in this discussion seem to
regard the policies of the ASF, don't deliver that.

Remember, like Sarbanes-Oxley intended with respect to how enterprises
conduct their business , per project bylaws feed into the aspect of
compliance to the ASF doctrine or explain when deviating on points.

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 Mon, Jul 6, 2015 at 10:18 AM, Bertrand Delacretaz  wrote:

> Hi,
>
> On Sun, Jul 5, 2015 at 6:30 AM, Pierre Smits 
> wrote:
> > if a project wants to deviate from the general rule of a simple
> > majority voting for specific aspects  - think off changing the direction
> or
> > goal of the project, or e.g. every registered contributor (iCLA filed)
> has
> > a vote with respect of onboarding new PMC Members - this must be
> > incorporated in the bylaws of a project
>
> This makes me feel like there you have an actual case behind this
> whole discussion.
>
> If that's correct, it might be easier to discuss the actual case
> rather than higher level and more abstract things.
>
> -Bertrand
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Branko Čibej]

On 04.07.2015 18:34, Pierre Smits wrote:
> Having done a cursory review of the incubator reports to the board for
> this year (January till May/June 2015), I found that only the SAMOA
> podling reported working on a project set of bylaws, which without
> knowing details could encompass and/or incorporate the code of conduct.

I find myself disgusted by this widespread assumption that each project
needs its own bylaws. WTF for? Are not ASF policies and practices enough
for everyone? What sort of bylaws could you possibly invent that are
both a useful extension of these policies and practices /and/ are not
applicable to other projects?

Per-project bylaws are just a tool for fragmenting the ASF community, in
other words, they're a bad idea; paper-shuffling at its most useless.

-- Brane

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Bertrand Delacretaz]

Hi,

On Sun, Jul 5, 2015 at 6:30 AM, Pierre Smits  wrote:
> if a project wants to deviate from the general rule of a simple
> majority voting for specific aspects  - think off changing the direction or
> goal of the project, or e.g. every registered contributor (iCLA filed) has
> a vote with respect of onboarding new PMC Members - this must be
> incorporated in the bylaws of a project

This makes me feel like there you have an actual case behind this
whole discussion.

If that's correct, it might be easier to discuss the actual case
rather than higher level and more abstract things.

-Bertrand

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[jan i]

On Sunday, July 5, 2015, Pierre Smits  wrote:

> Then again, Jan stated that he thought that instilling compliance to the
> official ASF policies, or expressions of deviation thereof, in the bylaws
> is a part of the incubation process. Is he wrong with his assumption? Or
> does the incubator project have it mixed up somewhere and he is right?


I did not mean that a oodling should create its own bylaws, but simply use
default and follow the ASF bylaws. Bylaws in projects should be (and are)
an exception.

rgds
jan i

>
> 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 Sun, Jul 5, 2015 at 1:46 AM, Pierre Smits  > wrote:
>
> > Is that just your opinion? Or something that is documented elsewhere as a
> > part of the rules of the game for projects of the ASF? And if so, where?
> >
> > 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 Sun, Jul 5, 2015 at 1:36 AM, Ross Gardler (MS OPEN TECH) <
> > ross.gard...@microsoft.com > wrote:
> >
> >> In the absence of bye-laws the defaults apply.
> >>
> >> Sent from my Windows Phone
> >> ____________
> >> From: Pierre Smits<mailto:pierre.sm...@gmail.com >
> >> Sent: ‎7/‎4/‎2015 3:35 PM
> >> To: dev@community.apache.org  dev@community.apache.org >
> >> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF
> (spin-off
> >> of Better specifying)
> >>
> >> How can that be? The board of the ASF explicitly tasks the projects (at
> >> least those that I have seen, as mentioned in my earlier posting) to
> >> establish a set of bylaws. That sounds like a binding clause for being a
> >> project of the ASF. The conclusion that can be derived from that is that
> >> the project that don't comply can't be an Apache project until that
> >> condition is met.
> >>
> >> 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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) <
> >> ross.gard...@microsoft.com > wrote:
> >>
> >> > No I said if projects don't write bye-laws then the defaults if the
> >> Apache
> >> > Way apply. If they have local bye-laws they are expected to be in the
> >> > spirit of the Apache Way but tuned to the specifics of that project.
> >> >
> >> > Sent from my Windows Phone
> >> > 
> >> > From: Pierre Smits<mailto:pierre.sm...@gmail.com >
> >> > Sent: ‎7/‎4/‎2015 3:16 PM
> >> > To: dev@community.apache.org  dev@community.apache.org >
> >> > Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> of
> >> > Better specifying)
> >> >
> >> > Off list?
> >> >
> >> > I am sure that quite a few more than just I couldn't
> >> > distill anything insightful or meaningful from your alrgument.
> >> >
> >> > So are we to understand that doing the right thing with respect to the
> >> > community is pushing paperwork? Doesn't that make the Community over
> >> Code
> >> > aspect of the Apache Way nothing more than a hollow phrase?
> >> >
> >> > Best regards,
> >> >
> >> > Pierre
> >> >
> >> > Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
> >> > ross.gard...@microsoft.com 
> >> >  ');>> het
> >> volgende
> >> > geschreven:
> >> >
> >> > > Sorry rushing and as has been pointed out off list auto-correct was
> >> not
> >> > > kind here.
> >> > >
> >> > > First sentence is unparseable so here it is again:
> >> > >
> >> > > The ASF is about doing the right thing in code, not pushing
> paperwork
> >> (or
> >> > > the electronic equivalent

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

I believe the point is that since we are about consensus it can (and in mt 
opinion should) be argued that rules are usually not necessary - respectful 
human interaction shouldn't require rules. Occasionally things break down, in 
such situations rules for conflict resolution become important, hence the 
defaults apply.

Sent from my Windows Phone

From: Pierre Smits<mailto:pierre.sm...@gmail.com>
Sent: ‎7/‎4/‎2015 9:30 PM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of 
Better specifying)

As it has been established in the "Veto! Veto?" thread that with procedural
issues a bit more is required than the generic statements in the Code of
Conduct and other pages describing the Apache Way.
Especially if a project wants to deviate from the general rule of a simple
majority voting for specific aspects  - think off changing the direction or
goal of the project, or e.g. every registered contributor (iCLA filed) has
a vote with respect of onboarding new PMC Members - this must be
incorporated in the bylaws of a project.

And these deviation must be checked against what the ASF states as its core
values.

That individuals regard bylaws as evil, doesn't make it less necessary.
Those who are at the good end of the stick never find such a necessity.
Bylaws exist to decribe the elements of due process.

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 Sun, Jul 5, 2015 at 4:47 AM, Roman Shaposhnik 
wrote:

> On Sat, Jul 4, 2015 at 4:12 PM, Benson Margulies 
> wrote:
> > In fact, I told at least one podling that bylaws are a faint smell of
> > trouble -- if you have enough conflict to feel the need to write down
> > the rules, you might do better working out the reason for the conflict
> > than writing down the rules.
>
> Just as Benson I'm writing this as somebody who mentored a whole
> bunch of podlings: early per-project bylawas are a sure sign of trouble
> in my book. Its the same issue as the community that runs a vote for
> every little thing imaginable.
>
> Both tend to create minorities and really get in the way of true consensus
> long term.
>
> Thanks,
> Roman.
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Niclas Hedhman]

Since Apache Zest (where I am the PMC Chair) was mentioned about called out
by the Board to create by-laws, I got curious to understand where that came
from, since I couldn't recall such order.

In reality, I wrote (copied) it myself in the Board Resolution to create
the project in the first place;


RESOLVED, that the initial Apache Zest Project be and hereby
   is tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   Apache Zest Project.


My guess is that this is a standard text from way back in time. Last time I
was involved in establishing a new project (Avalon) before Incubator, we
had a pointer to the Jakarta by-laws and I think that was perpetuated to a
point where it become the default position, until Jakarta is retired and
the origin of the "default" is gone.

Pierre may have a point in that the Board Resolution text could be
formulated differently to reflect this "default" and "lazy" position.

//Niclas
On Jul 4, 2015 18:35, "Pierre Smits"  wrote:

> >> Having such an official ASF policy without the executing office policing
> >> it, without podlings being required to accept and instill it in their
> >> bylaws before graduation and allowing existing projects not to
> incorporate
> >> it makes it nothing more than a hollow statement,
> >>
> > Being part of IPMC, I thought it was part of the incubator to make sure
> that
> > exactly this happened.
>
> Having done a cursory review of the incubator reports to the board for this
> year (January till May/June 2015), I found that only the SAMOA podling
> reported working on a project set of bylaws, which without knowing details
> could encompass and/or incorporate the code of conduct.
> None of the other podlings reported about that. Having looked also at the
> board reports for January up to May 2015 I found that podlings graduating
> to TLP were either tasked by the board to establish a set of bylaws or not.
>
> This tells me that acceptance/incorporation of the code of conduct of the
> ASF by the podlings is not a requirement.
> It might also mean - given the code of conduct as it is today - that IPMC
> members (as mentors) are either not fully aware that
> acceptance/incorporation is part of incubation process, or that they
> consider it optional.
>
> What I also observed from the board reports (minutes) from Jan till May is
> that while graduating podlings (as part of their establisment as a TLP)
> where tasked by the board to create a set of bylaws, that up to now those
> projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
> Zest) don't reference anything about a set of bylaws.
> And one graduating (Apache Samza) was not tasked with creating a set of
> bylaws at all by the board.
>
> It seems to me that this viewpoint of flexibility for projects has led to
> various approaches applied during the incubation phase. Making it harder to
> tell a unified story to the outside world...
> The Code of Conduct affects more the community aspect while being under the
> umbrella of the ASF than the code aspect. The Code of Conduct and the
> Apache Way (community over code) is foremost about how the contributors
> interact. About how to do just to all contributors, not how to favour a
> few
> The bylaws of a project should reflect how that is done, meaning defining
> the rules regarding procedural matters (which culminates about how the
> project deals with onboarding and ofboarding of contributors visavis
> privileges - commit privileges, PMC, PMC Chair).
>
> And shouldn't the VP of the project report back to the board, in the
> projects regular report, about the progress? And shouldn't the board keep
> track of what it has task the project to do, and/or check that a project's
> bylaws doesn't conflict with the Code of Conduct or the 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 Fri, Jul 3, 2015 at 12:10 PM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
> > Hi,
> >
> > As there was no opposition I have modified the first few paragraphs of
> > http://www.apache.org/foundation/policies/conduct.html as below.
> >
> > -Bertrand
> >
> > On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
> >  wrote:
> > > *** reworked code of conduct intro section ***
> > > This code of conduct applies to all spaces managed by the Apache
> > > Software Foundation, including IRC, all pub

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

As it has been established in the "Veto! Veto?" thread that with procedural
issues a bit more is required than the generic statements in the Code of
Conduct and other pages describing the Apache Way.
Especially if a project wants to deviate from the general rule of a simple
majority voting for specific aspects  - think off changing the direction or
goal of the project, or e.g. every registered contributor (iCLA filed) has
a vote with respect of onboarding new PMC Members - this must be
incorporated in the bylaws of a project.

And these deviation must be checked against what the ASF states as its core
values.

That individuals regard bylaws as evil, doesn't make it less necessary.
Those who are at the good end of the stick never find such a necessity.
Bylaws exist to decribe the elements of due process.

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 Sun, Jul 5, 2015 at 4:47 AM, Roman Shaposhnik 
wrote:

> On Sat, Jul 4, 2015 at 4:12 PM, Benson Margulies 
> wrote:
> > In fact, I told at least one podling that bylaws are a faint smell of
> > trouble -- if you have enough conflict to feel the need to write down
> > the rules, you might do better working out the reason for the conflict
> > than writing down the rules.
>
> Just as Benson I'm writing this as somebody who mentored a whole
> bunch of podlings: early per-project bylawas are a sure sign of trouble
> in my book. Its the same issue as the community that runs a vote for
> every little thing imaginable.
>
> Both tend to create minorities and really get in the way of true consensus
> long term.
>
> Thanks,
> Roman.
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Roman Shaposhnik]

On Sat, Jul 4, 2015 at 4:12 PM, Benson Margulies  wrote:
> In fact, I told at least one podling that bylaws are a faint smell of
> trouble -- if you have enough conflict to feel the need to write down
> the rules, you might do better working out the reason for the conflict
> than writing down the rules.

Just as Benson I'm writing this as somebody who mentored a whole
bunch of podlings: early per-project bylawas are a sure sign of trouble
in my book. Its the same issue as the community that runs a vote for
every little thing imaginable.

Both tend to create minorities and really get in the way of true consensus
long term.

Thanks,
Roman.

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

It's my opinion based on accepted practice (and the way I and fellow directors 
addressed non-technical disputes taken to the board). We've been operating like 
this since day one. Most project bye laws (that I've read) acknowledge the. 
E.g. 

Forrest: For more information about the way that Apache projects operate, 
please refer to the ASF foundation and ASF developer sections of the ASF 
website, including the ASF ByLaws and the How it works document, the FAQs about 
the Foundation, and the Incubator project.

Hive: Hive is typical of Apache projects in that it operates under a set of 
principles, known collectively as the 'Apache Way'. If you are new to Apache 
development, please refer to the Incubator Project for more information on how 
Apache projects operate.

Looking specifically at a code of conduct, the foundation has one and projects 
are expected to adopt it, or define something similar. It's part of the Apache 
Way. Note the code is deliberately written to allow appropriate flexibility for 
such a complex topic.

Ross


-Original Message-
From: Pierre Smits [mailto:pierre.sm...@gmail.com] 
Sent: Saturday, July 4, 2015 3:46 PM
To: dev@community.apache.org
Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of 
Better specifying)

Is that just your opinion? Or something that is documented elsewhere as a part 
of the rules of the game for projects of the ASF? And if so, where?

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 Sun, Jul 5, 2015 at 1:36 AM, Ross Gardler (MS OPEN TECH) < 
ross.gard...@microsoft.com> wrote:

> In the absence of bye-laws the defaults apply.
>
> Sent from my Windows Phone
> 
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ‎7/‎4/‎2015 3:35 PM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF 
> (spin-off of Better specifying)
>
> How can that be? The board of the ASF explicitly tasks the projects 
> (at least those that I have seen, as mentioned in my earlier posting) 
> to establish a set of bylaws. That sounds like a binding clause for 
> being a project of the ASF. The conclusion that can be derived from 
> that is that the project that don't comply can't be an Apache project 
> until that condition is met.
>
> 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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) < 
> ross.gard...@microsoft.com> wrote:
>
> > No I said if projects don't write bye-laws then the defaults if the
> Apache
> > Way apply. If they have local bye-laws they are expected to be in 
> > the spirit of the Apache Way but tuned to the specifics of that project.
> >
> > Sent from my Windows Phone
> > ____
> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> > Sent: ‎7/‎4/‎2015 3:16 PM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > Subject: Incubating, Graduating & Code of conduct @ The ASF 
> > (spin-off of Better specifying)
> >
> > Off list?
> >
> > I am sure that quite a few more than just I couldn't distill 
> > anything insightful or meaningful from your alrgument.
> >
> > So are we to understand that doing the right thing with respect to 
> > the community is pushing paperwork? Doesn't that make the Community 
> > over Code aspect of the Apache Way nothing more than a hollow phrase?
> >
> > Best regards,
> >
> > Pierre
> >
> > Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) < 
> > ross.gard...@microsoft.com 
> > > het
> volgende
> > geschreven:
> >
> > > Sorry rushing and as has been pointed out off list auto-correct 
> > > was not kind here.
> > >
> > > First sentence is unparseable so here it is again:
> > >
> > > The ASF is about doing the right thing in code, not pushing 
> > > paperwork
> (or
> > > the electronic equivalent).
> > >
> > > Sent from my Windows Phone
> > > 
> > > From: Ross Gardler (MS OPEN 
> > > TECH)<mailto:ross.gard...@microsoft.com>
> > > Sent: ‎7/‎4/‎2015 10:08 AM
> > > To: dev@community.apache.org<mailto:dev@community.a

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

Almost every board resolution to create a project contains...

RESOLVED, that the initial PROJECT PMC be and hereby is
  tasked with the creation of a set of bylaws intended to
  encourage open development and increased participation in the
  PROJECT; and be it further

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Saturday, July 4, 2015 4:13 PM
To: dev@community.apache.org
Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of 
Better specifying)

Writing as someone who has mentored a squad of podlings, I do not believe that 
there is any requirement for any project to ever adopt any bylaws at all. I was 
never involved where the board ask for bylaws, and I'm faintly curious as to 
how that ever came to pass. The normal process is for podlings to simply apply 
standard ASF procedures to manage code and community. I view the Foundation CoC 
as part of that.

In fact, I told at least one podling that bylaws are a faint smell of trouble 
-- if you have enough conflict to feel the need to write down the rules, you 
might do better working out the reason for the conflict than writing down the 
rules.

However, I recognized that some communities have some inescapable stresses due 
to conflicting commercial interests, and some bylaws early can be a way to head 
off drama later.

However, I can't imagine anyone thinking that the Foundation CoC fails to apply 
in the absence of a set of bylaws. I also can't imagine any person thinking 
that a set of bylaws that doesn't happen to mention the CoC somehow excludes 
it. Project are part of the ASF. They don't have independent legal existence. 
Their 'bylaws' are not corporate, legal, bylaws, they are just a 
memorialization of their policies. They don't have to be comprehensive.

On Sat, Jul 4, 2015 at 6:53 PM, Pierre Smits  wrote:
> Then again, Jan stated that he thought that instilling compliance to 
> the official ASF policies, or expressions of deviation thereof, in the 
> bylaws is a part of the incubation process. Is he wrong with his 
> assumption? Or does the incubator project have it mixed up somewhere and he 
> is right?
>
> 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 Sun, Jul 5, 2015 at 1:46 AM, Pierre Smits  wrote:
>
>> Is that just your opinion? Or something that is documented elsewhere 
>> as a part of the rules of the game for projects of the ASF? And if so, where?
>>
>> 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 Sun, Jul 5, 2015 at 1:36 AM, Ross Gardler (MS OPEN TECH) < 
>> ross.gard...@microsoft.com> wrote:
>>
>>> In the absence of bye-laws the defaults apply.
>>>
>>> Sent from my Windows Phone
>>> 
>>> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
>>> Sent: ‎7/‎4/‎2015 3:35 PM
>>> To: dev@community.apache.org<mailto:dev@community.apache.org>
>>> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF 
>>> (spin-off of Better specifying)
>>>
>>> How can that be? The board of the ASF explicitly tasks the projects 
>>> (at least those that I have seen, as mentioned in my earlier 
>>> posting) to establish a set of bylaws. That sounds like a binding 
>>> clause for being a project of the ASF. The conclusion that can be 
>>> derived from that is that the project that don't comply can't be an 
>>> Apache project until that condition is met.
>>>
>>> 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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) < 
>>> ross.gard...@microsoft.com> wrote:
>>>
>>> > No I said if projects don't write bye-laws then the defaults if 
>>> > the
>>> Apache
>>> > Way apply. If they have local bye-laws they are expected to be in 
>>> > the spirit of the Apache Way but tuned to the specifics of that project.
>>> >
>>> > Sent from my Windows Phone
>>> > 
>>> >

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Benson Margulies]

Writing as someone who has mentored a squad of podlings, I do not
believe that there is any requirement for any project to ever adopt
any bylaws at all. I was never involved where the board ask for
bylaws, and I'm faintly curious as to how that ever came to pass. The
normal process is for podlings to simply apply standard ASF procedures
to manage code and community. I view the Foundation CoC as part of
that.

In fact, I told at least one podling that bylaws are a faint smell of
trouble -- if you have enough conflict to feel the need to write down
the rules, you might do better working out the reason for the conflict
than writing down the rules.

However, I recognized that some communities have some inescapable
stresses due to conflicting commercial interests, and some bylaws
early can be a way to head off drama later.

However, I can't imagine anyone thinking that the Foundation CoC fails
to apply in the absence of a set of bylaws. I also can't imagine any
person thinking that a set of bylaws that doesn't happen to mention
the CoC somehow excludes it. Project are part of the ASF. They don't
have independent legal existence. Their 'bylaws' are not corporate,
legal, bylaws, they are just a memorialization of their policies. They
don't have to be comprehensive.

On Sat, Jul 4, 2015 at 6:53 PM, Pierre Smits  wrote:
> Then again, Jan stated that he thought that instilling compliance to the
> official ASF policies, or expressions of deviation thereof, in the bylaws
> is a part of the incubation process. Is he wrong with his assumption? Or
> does the incubator project have it mixed up somewhere and he is right?
>
> 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 Sun, Jul 5, 2015 at 1:46 AM, Pierre Smits  wrote:
>
>> Is that just your opinion? Or something that is documented elsewhere as a
>> part of the rules of the game for projects of the ASF? And if so, where?
>>
>> 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 Sun, Jul 5, 2015 at 1:36 AM, Ross Gardler (MS OPEN TECH) <
>> ross.gard...@microsoft.com> wrote:
>>
>>> In the absence of bye-laws the defaults apply.
>>>
>>> Sent from my Windows Phone
>>> 
>>> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
>>> Sent: ‎7/‎4/‎2015 3:35 PM
>>> To: dev@community.apache.org<mailto:dev@community.apache.org>
>>> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off
>>> of Better specifying)
>>>
>>> How can that be? The board of the ASF explicitly tasks the projects (at
>>> least those that I have seen, as mentioned in my earlier posting) to
>>> establish a set of bylaws. That sounds like a binding clause for being a
>>> project of the ASF. The conclusion that can be derived from that is that
>>> the project that don't comply can't be an Apache project until that
>>> condition is met.
>>>
>>> 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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) <
>>> ross.gard...@microsoft.com> wrote:
>>>
>>> > No I said if projects don't write bye-laws then the defaults if the
>>> Apache
>>> > Way apply. If they have local bye-laws they are expected to be in the
>>> > spirit of the Apache Way but tuned to the specifics of that project.
>>> >
>>> > Sent from my Windows Phone
>>> > 
>>> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
>>> > Sent: ‎7/‎4/‎2015 3:16 PM
>>> > To: dev@community.apache.org<mailto:dev@community.apache.org>
>>> > Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
>>> > Better specifying)
>>> >
>>> > Off list?
>>> >
>>> > I am sure that quite a few more than just I couldn't
>>> > distill anything insightful or meaningful from your alrgument.
>

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Then again, Jan stated that he thought that instilling compliance to the
official ASF policies, or expressions of deviation thereof, in the bylaws
is a part of the incubation process. Is he wrong with his assumption? Or
does the incubator project have it mixed up somewhere and he is right?

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 Sun, Jul 5, 2015 at 1:46 AM, Pierre Smits  wrote:

> Is that just your opinion? Or something that is documented elsewhere as a
> part of the rules of the game for projects of the ASF? And if so, where?
>
> 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 Sun, Jul 5, 2015 at 1:36 AM, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com> wrote:
>
>> In the absence of bye-laws the defaults apply.
>>
>> Sent from my Windows Phone
>> 
>> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
>> Sent: ‎7/‎4/‎2015 3:35 PM
>> To: dev@community.apache.org<mailto:dev@community.apache.org>
>> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off
>> of Better specifying)
>>
>> How can that be? The board of the ASF explicitly tasks the projects (at
>> least those that I have seen, as mentioned in my earlier posting) to
>> establish a set of bylaws. That sounds like a binding clause for being a
>> project of the ASF. The conclusion that can be derived from that is that
>> the project that don't comply can't be an Apache project until that
>> condition is met.
>>
>> 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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) <
>> ross.gard...@microsoft.com> wrote:
>>
>> > No I said if projects don't write bye-laws then the defaults if the
>> Apache
>> > Way apply. If they have local bye-laws they are expected to be in the
>> > spirit of the Apache Way but tuned to the specifics of that project.
>> >
>> > Sent from my Windows Phone
>> > 
>> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
>> > Sent: ‎7/‎4/‎2015 3:16 PM
>> > To: dev@community.apache.org<mailto:dev@community.apache.org>
>> > Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
>> > Better specifying)
>> >
>> > Off list?
>> >
>> > I am sure that quite a few more than just I couldn't
>> > distill anything insightful or meaningful from your alrgument.
>> >
>> > So are we to understand that doing the right thing with respect to the
>> > community is pushing paperwork? Doesn't that make the Community over
>> Code
>> > aspect of the Apache Way nothing more than a hollow phrase?
>> >
>> > Best regards,
>> >
>> > Pierre
>> >
>> > Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
>> > ross.gard...@microsoft.com
>> > > het
>> volgende
>> > geschreven:
>> >
>> > > Sorry rushing and as has been pointed out off list auto-correct was
>> not
>> > > kind here.
>> > >
>> > > First sentence is unparseable so here it is again:
>> > >
>> > > The ASF is about doing the right thing in code, not pushing paperwork
>> (or
>> > > the electronic equivalent).
>> > >
>> > > Sent from my Windows Phone
>> > > 
>> > > From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
>> > > Sent: ‎7/‎4/‎2015 10:08 AM
>> > > To: dev@community.apache.org<mailto:dev@community.apache.org>
>> > > Subject: RE: Incubating, Graduating & Code of conduct @ The ASF
>> (spin-off
>> > > of Better specifying)
>> > >
>> > > The ASF is about doing the right thing in code, not loading passport
>> (our
>> > > the electronic equivalent). There are default position for most
>> > situations
>> > > in a pro

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Is that just your opinion? Or something that is documented elsewhere as a
part of the rules of the game for projects of the ASF? And if so, where?

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 Sun, Jul 5, 2015 at 1:36 AM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> In the absence of bye-laws the defaults apply.
>
> Sent from my Windows Phone
> 
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ‎7/‎4/‎2015 3:35 PM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> of Better specifying)
>
> How can that be? The board of the ASF explicitly tasks the projects (at
> least those that I have seen, as mentioned in my earlier posting) to
> establish a set of bylaws. That sounds like a binding clause for being a
> project of the ASF. The conclusion that can be derived from that is that
> the project that don't comply can't be an Apache project until that
> condition is met.
>
> 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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com> wrote:
>
> > No I said if projects don't write bye-laws then the defaults if the
> Apache
> > Way apply. If they have local bye-laws they are expected to be in the
> > spirit of the Apache Way but tuned to the specifics of that project.
> >
> > Sent from my Windows Phone
> > ________
> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> > Sent: ‎7/‎4/‎2015 3:16 PM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> > Better specifying)
> >
> > Off list?
> >
> > I am sure that quite a few more than just I couldn't
> > distill anything insightful or meaningful from your alrgument.
> >
> > So are we to understand that doing the right thing with respect to the
> > community is pushing paperwork? Doesn't that make the Community over Code
> > aspect of the Apache Way nothing more than a hollow phrase?
> >
> > Best regards,
> >
> > Pierre
> >
> > Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
> > ross.gard...@microsoft.com
> > > het
> volgende
> > geschreven:
> >
> > > Sorry rushing and as has been pointed out off list auto-correct was not
> > > kind here.
> > >
> > > First sentence is unparseable so here it is again:
> > >
> > > The ASF is about doing the right thing in code, not pushing paperwork
> (or
> > > the electronic equivalent).
> > >
> > > Sent from my Windows Phone
> > > 
> > > From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
> > > Sent: ‎7/‎4/‎2015 10:08 AM
> > > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > > Subject: RE: Incubating, Graduating & Code of conduct @ The ASF
> (spin-off
> > > of Better specifying)
> > >
> > > The ASF is about doing the right thing in code, not loading passport
> (our
> > > the electronic equivalent). There are default position for most
> > situations
> > > in a project. In the absence of project specific exceptions the default
> > > applies. Most projects are happy with the default and prefer to write
> > code
> > > instead.
> > >
> > > Where a project has local exceptions they must conform to the spirit of
> > > the Apache Way. If they don't then the community can turn to the PMC
> (and
> > > if necessary the board) to address areas of concern.
> > >
> > > It's always possible to better document things, but the documentation
> is
> > > there. E.g.
> > >
> >
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> > > and http://www.apache.org/foundation/how-it-works.html
> > >
> > > Ross
> > >
> > >
> > >
> > > Sent from my Windows Phone
> > > 
> > > From: Pierre Smits<mailto:pierre.sm...@g

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

In the absence of bye-laws the defaults apply.

Sent from my Windows Phone

From: Pierre Smits<mailto:pierre.sm...@gmail.com>
Sent: ‎7/‎4/‎2015 3:35 PM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of 
Better specifying)

How can that be? The board of the ASF explicitly tasks the projects (at
least those that I have seen, as mentioned in my earlier posting) to
establish a set of bylaws. That sounds like a binding clause for being a
project of the ASF. The conclusion that can be derived from that is that
the project that don't comply can't be an Apache project until that
condition is met.

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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> No I said if projects don't write bye-laws then the defaults if the Apache
> Way apply. If they have local bye-laws they are expected to be in the
> spirit of the Apache Way but tuned to the specifics of that project.
>
> Sent from my Windows Phone
> 
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ‎7/‎4/‎2015 3:16 PM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> Better specifying)
>
> Off list?
>
> I am sure that quite a few more than just I couldn't
> distill anything insightful or meaningful from your alrgument.
>
> So are we to understand that doing the right thing with respect to the
> community is pushing paperwork? Doesn't that make the Community over Code
> aspect of the Apache Way nothing more than a hollow phrase?
>
> Best regards,
>
> Pierre
>
> Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com
> > het volgende
> geschreven:
>
> > Sorry rushing and as has been pointed out off list auto-correct was not
> > kind here.
> >
> > First sentence is unparseable so here it is again:
> >
> > The ASF is about doing the right thing in code, not pushing paperwork (or
> > the electronic equivalent).
> >
> > Sent from my Windows Phone
> > ________
> > From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
> > Sent: ‎7/‎4/‎2015 10:08 AM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > Subject: RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> > of Better specifying)
> >
> > The ASF is about doing the right thing in code, not loading passport (our
> > the electronic equivalent). There are default position for most
> situations
> > in a project. In the absence of project specific exceptions the default
> > applies. Most projects are happy with the default and prefer to write
> code
> > instead.
> >
> > Where a project has local exceptions they must conform to the spirit of
> > the Apache Way. If they don't then the community can turn to the PMC (and
> > if necessary the board) to address areas of concern.
> >
> > It's always possible to better document things, but the documentation is
> > there. E.g.
> >
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> > and http://www.apache.org/foundation/how-it-works.html
> >
> > Ross
> >
> >
> >
> > Sent from my Windows Phone
> > 
> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> > Sent: ‎7/‎4/‎2015 9:34 AM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> > Better specifying)
> >
> > >> Having such an official ASF policy without the executing office
> policing
> > >> it, without podlings being required to accept and instill it in their
> > >> bylaws before graduation and allowing existing projects not to
> > incorporate
> > >> it makes it nothing more than a hollow statement,
> > >>
> > > Being part of IPMC, I thought it was part of the incubator to make sure
> > that
> > > exactly this happened.
> >
> > Having done a cursory review of the incubator reports to the board for
> this
> > year (January till May/June 2015), I found that only the SAMOA podling
> > reported working o

Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

How can that be? The board of the ASF explicitly tasks the projects (at
least those that I have seen, as mentioned in my earlier posting) to
establish a set of bylaws. That sounds like a binding clause for being a
project of the ASF. The conclusion that can be derived from that is that
the project that don't comply can't be an Apache project until that
condition is met.

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 Sun, Jul 5, 2015 at 1:28 AM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> No I said if projects don't write bye-laws then the defaults if the Apache
> Way apply. If they have local bye-laws they are expected to be in the
> spirit of the Apache Way but tuned to the specifics of that project.
>
> Sent from my Windows Phone
> 
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ‎7/‎4/‎2015 3:16 PM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> Better specifying)
>
> Off list?
>
> I am sure that quite a few more than just I couldn't
> distill anything insightful or meaningful from your alrgument.
>
> So are we to understand that doing the right thing with respect to the
> community is pushing paperwork? Doesn't that make the Community over Code
> aspect of the Apache Way nothing more than a hollow phrase?
>
> Best regards,
>
> Pierre
>
> Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com
> > het volgende
> geschreven:
>
> > Sorry rushing and as has been pointed out off list auto-correct was not
> > kind here.
> >
> > First sentence is unparseable so here it is again:
> >
> > The ASF is about doing the right thing in code, not pushing paperwork (or
> > the electronic equivalent).
> >
> > Sent from my Windows Phone
> > 
> > From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
> > Sent: ‎7/‎4/‎2015 10:08 AM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > Subject: RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> > of Better specifying)
> >
> > The ASF is about doing the right thing in code, not loading passport (our
> > the electronic equivalent). There are default position for most
> situations
> > in a project. In the absence of project specific exceptions the default
> > applies. Most projects are happy with the default and prefer to write
> code
> > instead.
> >
> > Where a project has local exceptions they must conform to the spirit of
> > the Apache Way. If they don't then the community can turn to the PMC (and
> > if necessary the board) to address areas of concern.
> >
> > It's always possible to better document things, but the documentation is
> > there. E.g.
> >
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> > and http://www.apache.org/foundation/how-it-works.html
> >
> > Ross
> >
> >
> >
> > Sent from my Windows Phone
> > 
> > From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> > Sent: ‎7/‎4/‎2015 9:34 AM
> > To: dev@community.apache.org<mailto:dev@community.apache.org>
> > Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> > Better specifying)
> >
> > >> Having such an official ASF policy without the executing office
> policing
> > >> it, without podlings being required to accept and instill it in their
> > >> bylaws before graduation and allowing existing projects not to
> > incorporate
> > >> it makes it nothing more than a hollow statement,
> > >>
> > > Being part of IPMC, I thought it was part of the incubator to make sure
> > that
> > > exactly this happened.
> >
> > Having done a cursory review of the incubator reports to the board for
> this
> > year (January till May/June 2015), I found that only the SAMOA podling
> > reported working on a project set of bylaws, which without knowing
> details
> > could encompass and/or incorporate the code of conduct.
> > None of the other podlings reported about that. Having looked also at the
> > board reports for January up to May 2015 I found that podlings graduating
> > to TLP were either tasked by the board to establish a set o

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

No I said if projects don't write bye-laws then the defaults if the Apache Way 
apply. If they have local bye-laws they are expected to be in the spirit of the 
Apache Way but tuned to the specifics of that project.

Sent from my Windows Phone

From: Pierre Smits<mailto:pierre.sm...@gmail.com>
Sent: ‎7/‎4/‎2015 3:16 PM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better 
specifying)

Off list?

I am sure that quite a few more than just I couldn't
distill anything insightful or meaningful from your alrgument.

So are we to understand that doing the right thing with respect to the
community is pushing paperwork? Doesn't that make the Community over Code
aspect of the Apache Way nothing more than a hollow phrase?

Best regards,

Pierre

Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com
> het volgende
geschreven:

> Sorry rushing and as has been pointed out off list auto-correct was not
> kind here.
>
> First sentence is unparseable so here it is again:
>
> The ASF is about doing the right thing in code, not pushing paperwork (or
> the electronic equivalent).
>
> Sent from my Windows Phone
> 
> From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
> Sent: ‎7/‎4/‎2015 10:08 AM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> of Better specifying)
>
> The ASF is about doing the right thing in code, not loading passport (our
> the electronic equivalent). There are default position for most situations
> in a project. In the absence of project specific exceptions the default
> applies. Most projects are happy with the default and prefer to write code
> instead.
>
> Where a project has local exceptions they must conform to the spirit of
> the Apache Way. If they don't then the community can turn to the PMC (and
> if necessary the board) to address areas of concern.
>
> It's always possible to better document things, but the documentation is
> there. E.g.
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> and http://www.apache.org/foundation/how-it-works.html
>
> Ross
>
>
>
> Sent from my Windows Phone
> 
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ‎7/‎4/‎2015 9:34 AM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> Better specifying)
>
> >> Having such an official ASF policy without the executing office policing
> >> it, without podlings being required to accept and instill it in their
> >> bylaws before graduation and allowing existing projects not to
> incorporate
> >> it makes it nothing more than a hollow statement,
> >>
> > Being part of IPMC, I thought it was part of the incubator to make sure
> that
> > exactly this happened.
>
> Having done a cursory review of the incubator reports to the board for this
> year (January till May/June 2015), I found that only the SAMOA podling
> reported working on a project set of bylaws, which without knowing details
> could encompass and/or incorporate the code of conduct.
> None of the other podlings reported about that. Having looked also at the
> board reports for January up to May 2015 I found that podlings graduating
> to TLP were either tasked by the board to establish a set of bylaws or not.
>
> This tells me that acceptance/incorporation of the code of conduct of the
> ASF by the podlings is not a requirement.
> It might also mean - given the code of conduct as it is today - that IPMC
> members (as mentors) are either not fully aware that
> acceptance/incorporation is part of incubation process, or that they
> consider it optional.
>
> What I also observed from the board reports (minutes) from Jan till May is
> that while graduating podlings (as part of their establisment as a TLP)
> where tasked by the board to create a set of bylaws, that up to now those
> projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
> Zest) don't reference anything about a set of bylaws.
> And one graduating (Apache Samza) was not tasked with creating a set of
> bylaws at all by the board.
>
> It seems to me that this viewpoint of flexibility for projects has led to
> various approaches applied during the incubation phase. Making it harder to
> tell a unified story to the outside world...
> The Code of Conduct affects more the community aspect 

Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

Off list?

I am sure that quite a few more than just I couldn't
distill anything insightful or meaningful from your alrgument.

So are we to understand that doing the right thing with respect to the
community is pushing paperwork? Doesn't that make the Community over Code
aspect of the Apache Way nothing more than a hollow phrase?

Best regards,

Pierre

Op zaterdag 4 juli 2015 heeft Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com
> het volgende
geschreven:

> Sorry rushing and as has been pointed out off list auto-correct was not
> kind here.
>
> First sentence is unparseable so here it is again:
>
> The ASF is about doing the right thing in code, not pushing paperwork (or
> the electronic equivalent).
>
> Sent from my Windows Phone
> 
> From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
> Sent: ‎7/‎4/‎2015 10:08 AM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off
> of Better specifying)
>
> The ASF is about doing the right thing in code, not loading passport (our
> the electronic equivalent). There are default position for most situations
> in a project. In the absence of project specific exceptions the default
> applies. Most projects are happy with the default and prefer to write code
> instead.
>
> Where a project has local exceptions they must conform to the spirit of
> the Apache Way. If they don't then the community can turn to the PMC (and
> if necessary the board) to address areas of concern.
>
> It's always possible to better document things, but the documentation is
> there. E.g.
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> and http://www.apache.org/foundation/how-it-works.html
>
> Ross
>
>
>
> Sent from my Windows Phone
> 
> From: Pierre Smits<mailto:pierre.sm...@gmail.com>
> Sent: ‎7/‎4/‎2015 9:34 AM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of
> Better specifying)
>
> >> Having such an official ASF policy without the executing office policing
> >> it, without podlings being required to accept and instill it in their
> >> bylaws before graduation and allowing existing projects not to
> incorporate
> >> it makes it nothing more than a hollow statement,
> >>
> > Being part of IPMC, I thought it was part of the incubator to make sure
> that
> > exactly this happened.
>
> Having done a cursory review of the incubator reports to the board for this
> year (January till May/June 2015), I found that only the SAMOA podling
> reported working on a project set of bylaws, which without knowing details
> could encompass and/or incorporate the code of conduct.
> None of the other podlings reported about that. Having looked also at the
> board reports for January up to May 2015 I found that podlings graduating
> to TLP were either tasked by the board to establish a set of bylaws or not.
>
> This tells me that acceptance/incorporation of the code of conduct of the
> ASF by the podlings is not a requirement.
> It might also mean - given the code of conduct as it is today - that IPMC
> members (as mentors) are either not fully aware that
> acceptance/incorporation is part of incubation process, or that they
> consider it optional.
>
> What I also observed from the board reports (minutes) from Jan till May is
> that while graduating podlings (as part of their establisment as a TLP)
> where tasked by the board to create a set of bylaws, that up to now those
> projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
> Zest) don't reference anything about a set of bylaws.
> And one graduating (Apache Samza) was not tasked with creating a set of
> bylaws at all by the board.
>
> It seems to me that this viewpoint of flexibility for projects has led to
> various approaches applied during the incubation phase. Making it harder to
> tell a unified story to the outside world...
> The Code of Conduct affects more the community aspect while being under the
> umbrella of the ASF than the code aspect. The Code of Conduct and the
> Apache Way (community over code) is foremost about how the contributors
> interact. About how to do just to all contributors, not how to favour a
> few
> The bylaws of a project should reflect how that is done, meaning defining
> the rules regarding procedural matters (which culminates about how the
> project deals with onboarding and ofboarding of contributors visavis
> privileges - commit privileges, 

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

Sorry rushing and as has been pointed out off list auto-correct was not kind 
here.

First sentence is unparseable so here it is again:

The ASF is about doing the right thing in code, not pushing paperwork (or the 
electronic equivalent).

Sent from my Windows Phone

From: Ross Gardler (MS OPEN TECH)<mailto:ross.gard...@microsoft.com>
Sent: ‎7/‎4/‎2015 10:08 AM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of 
Better specifying)

The ASF is about doing the right thing in code, not loading passport (our the 
electronic equivalent). There are default position for most situations in a 
project. In the absence of project specific exceptions the default applies. 
Most projects are happy with the default and prefer to write code instead.

Where a project has local exceptions they must conform to the spirit of the 
Apache Way. If they don't then the community can turn to the PMC (and if 
necessary the board) to address areas of concern.

It's always possible to better document things, but the documentation is there. 
E.g. http://community.apache.org/apache-way/apache-project-maturity-model.html 
and http://www.apache.org/foundation/how-it-works.html

Ross



Sent from my Windows Phone

From: Pierre Smits<mailto:pierre.sm...@gmail.com>
Sent: ‎7/‎4/‎2015 9:34 AM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better 
specifying)

>> Having such an official ASF policy without the executing office policing
>> it, without podlings being required to accept and instill it in their
>> bylaws before graduation and allowing existing projects not to
incorporate
>> it makes it nothing more than a hollow statement,
>>
> Being part of IPMC, I thought it was part of the incubator to make sure
that
> exactly this happened.

Having done a cursory review of the incubator reports to the board for this
year (January till May/June 2015), I found that only the SAMOA podling
reported working on a project set of bylaws, which without knowing details
could encompass and/or incorporate the code of conduct.
None of the other podlings reported about that. Having looked also at the
board reports for January up to May 2015 I found that podlings graduating
to TLP were either tasked by the board to establish a set of bylaws or not.

This tells me that acceptance/incorporation of the code of conduct of the
ASF by the podlings is not a requirement.
It might also mean - given the code of conduct as it is today - that IPMC
members (as mentors) are either not fully aware that
acceptance/incorporation is part of incubation process, or that they
consider it optional.

What I also observed from the board reports (minutes) from Jan till May is
that while graduating podlings (as part of their establisment as a TLP)
where tasked by the board to create a set of bylaws, that up to now those
projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
Zest) don't reference anything about a set of bylaws.
And one graduating (Apache Samza) was not tasked with creating a set of
bylaws at all by the board.

It seems to me that this viewpoint of flexibility for projects has led to
various approaches applied during the incubation phase. Making it harder to
tell a unified story to the outside world...
The Code of Conduct affects more the community aspect while being under the
umbrella of the ASF than the code aspect. The Code of Conduct and the
Apache Way (community over code) is foremost about how the contributors
interact. About how to do just to all contributors, not how to favour a
few
The bylaws of a project should reflect how that is done, meaning defining
the rules regarding procedural matters (which culminates about how the
project deals with onboarding and ofboarding of contributors visavis
privileges - commit privileges, PMC, PMC Chair).

And shouldn't the VP of the project report back to the board, in the
projects regular report, about the progress? And shouldn't the board keep
track of what it has task the project to do, and/or check that a project's
bylaws doesn't conflict with the Code of Conduct or the 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 Fri, Jul 3, 2015 at 12:10 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> As there was no opposition I have modified the first few paragraphs of
> http://www.apache.org/foundation/policies/conduct.html as below.
>
> -Bertrand
>
> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
>  wrote:
> > *** reworked code of conduct intro section ***
> &

RE: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Ross Gardler (MS OPEN TECH)]

The ASF is about doing the right thing in code, not loading passport (our the 
electronic equivalent). There are default position for most situations in a 
project. In the absence of project specific exceptions the default applies. 
Most projects are happy with the default and prefer to write code instead.

Where a project has local exceptions they must conform to the spirit of the 
Apache Way. If they don't then the community can turn to the PMC (and if 
necessary the board) to address areas of concern.

It's always possible to better document things, but the documentation is there. 
E.g. http://community.apache.org/apache-way/apache-project-maturity-model.html 
and http://www.apache.org/foundation/how-it-works.html

Ross



Sent from my Windows Phone

From: Pierre Smits<mailto:pierre.sm...@gmail.com>
Sent: ‎7/‎4/‎2015 9:34 AM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better 
specifying)

>> Having such an official ASF policy without the executing office policing
>> it, without podlings being required to accept and instill it in their
>> bylaws before graduation and allowing existing projects not to
incorporate
>> it makes it nothing more than a hollow statement,
>>
> Being part of IPMC, I thought it was part of the incubator to make sure
that
> exactly this happened.

Having done a cursory review of the incubator reports to the board for this
year (January till May/June 2015), I found that only the SAMOA podling
reported working on a project set of bylaws, which without knowing details
could encompass and/or incorporate the code of conduct.
None of the other podlings reported about that. Having looked also at the
board reports for January up to May 2015 I found that podlings graduating
to TLP were either tasked by the board to establish a set of bylaws or not.

This tells me that acceptance/incorporation of the code of conduct of the
ASF by the podlings is not a requirement.
It might also mean - given the code of conduct as it is today - that IPMC
members (as mentors) are either not fully aware that
acceptance/incorporation is part of incubation process, or that they
consider it optional.

What I also observed from the board reports (minutes) from Jan till May is
that while graduating podlings (as part of their establisment as a TLP)
where tasked by the board to create a set of bylaws, that up to now those
projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
Zest) don't reference anything about a set of bylaws.
And one graduating (Apache Samza) was not tasked with creating a set of
bylaws at all by the board.

It seems to me that this viewpoint of flexibility for projects has led to
various approaches applied during the incubation phase. Making it harder to
tell a unified story to the outside world...
The Code of Conduct affects more the community aspect while being under the
umbrella of the ASF than the code aspect. The Code of Conduct and the
Apache Way (community over code) is foremost about how the contributors
interact. About how to do just to all contributors, not how to favour a
few
The bylaws of a project should reflect how that is done, meaning defining
the rules regarding procedural matters (which culminates about how the
project deals with onboarding and ofboarding of contributors visavis
privileges - commit privileges, PMC, PMC Chair).

And shouldn't the VP of the project report back to the board, in the
projects regular report, about the progress? And shouldn't the board keep
track of what it has task the project to do, and/or check that a project's
bylaws doesn't conflict with the Code of Conduct or the 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 Fri, Jul 3, 2015 at 12:10 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> As there was no opposition I have modified the first few paragraphs of
> http://www.apache.org/foundation/policies/conduct.html as below.
>
> -Bertrand
>
> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
>  wrote:
> > *** reworked code of conduct intro section ***
> > This code of conduct applies to all spaces managed by the Apache
> > Software Foundation, including IRC, all public and private mailing
> > lists, issue trackers, wikis, blogs, Twitter, and any other
> > communication channel used by our communities. A code of conduct which
> > is specific to in-person events (ie., conferences) is codified in the
> > published ASF anti-harassment policy.
> >
> > We expect this code of conduct to be honored by everyone who
> > participates in the Apache community formally or informall

Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)

[Pierre Smits]

>> Having such an official ASF policy without the executing office policing
>> it, without podlings being required to accept and instill it in their
>> bylaws before graduation and allowing existing projects not to
incorporate
>> it makes it nothing more than a hollow statement,
>>
> Being part of IPMC, I thought it was part of the incubator to make sure
that
> exactly this happened.

Having done a cursory review of the incubator reports to the board for this
year (January till May/June 2015), I found that only the SAMOA podling
reported working on a project set of bylaws, which without knowing details
could encompass and/or incorporate the code of conduct.
None of the other podlings reported about that. Having looked also at the
board reports for January up to May 2015 I found that podlings graduating
to TLP were either tasked by the board to establish a set of bylaws or not.

This tells me that acceptance/incorporation of the code of conduct of the
ASF by the podlings is not a requirement.
It might also mean - given the code of conduct as it is today - that IPMC
members (as mentors) are either not fully aware that
acceptance/incorporation is part of incubation process, or that they
consider it optional.

What I also observed from the board reports (minutes) from Jan till May is
that while graduating podlings (as part of their establisment as a TLP)
where tasked by the board to create a set of bylaws, that up to now those
projects (Apache Whimsy, Apache Orc, Apache Parquet, Apache Aurora, Apache
Zest) don't reference anything about a set of bylaws.
And one graduating (Apache Samza) was not tasked with creating a set of
bylaws at all by the board.

It seems to me that this viewpoint of flexibility for projects has led to
various approaches applied during the incubation phase. Making it harder to
tell a unified story to the outside world...
The Code of Conduct affects more the community aspect while being under the
umbrella of the ASF than the code aspect. The Code of Conduct and the
Apache Way (community over code) is foremost about how the contributors
interact. About how to do just to all contributors, not how to favour a
few
The bylaws of a project should reflect how that is done, meaning defining
the rules regarding procedural matters (which culminates about how the
project deals with onboarding and ofboarding of contributors visavis
privileges - commit privileges, PMC, PMC Chair).

And shouldn't the VP of the project report back to the board, in the
projects regular report, about the progress? And shouldn't the board keep
track of what it has task the project to do, and/or check that a project's
bylaws doesn't conflict with the Code of Conduct or the 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 Fri, Jul 3, 2015 at 12:10 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> As there was no opposition I have modified the first few paragraphs of
> http://www.apache.org/foundation/policies/conduct.html as below.
>
> -Bertrand
>
> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
>  wrote:
> > *** reworked code of conduct intro section ***
> > This code of conduct applies to all spaces managed by the Apache
> > Software Foundation, including IRC, all public and private mailing
> > lists, issue trackers, wikis, blogs, Twitter, and any other
> > communication channel used by our communities. A code of conduct which
> > is specific to in-person events (ie., conferences) is codified in the
> > published ASF anti-harassment policy.
> >
> > We expect this code of conduct to be honored by everyone who
> > participates in the Apache community formally or informally, or claims
> > any affiliation with the Foundation, in any Foundation-related
> > activities and especially when representing the ASF, in any role.
> >
> > This code is not exhaustive or complete(unchanged from here on)
> > *** reworked code of conduct intro section ***
>

Re: Better specifying the scope of our Code of Conduct

[Bertrand Delacretaz]

Hi,

As there was no opposition I have modified the first few paragraphs of
http://www.apache.org/foundation/policies/conduct.html as below.

-Bertrand

On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
 wrote:
> *** reworked code of conduct intro section ***
> This code of conduct applies to all spaces managed by the Apache
> Software Foundation, including IRC, all public and private mailing
> lists, issue trackers, wikis, blogs, Twitter, and any other
> communication channel used by our communities. A code of conduct which
> is specific to in-person events (ie., conferences) is codified in the
> published ASF anti-harassment policy.
>
> We expect this code of conduct to be honored by everyone who
> participates in the Apache community formally or informally, or claims
> any affiliation with the Foundation, in any Foundation-related
> activities and especially when representing the ASF, in any role.
>
> This code is not exhaustive or complete....(unchanged from here on)
> *** reworked code of conduct intro section ***

Re: Better specifying the scope of our Code of Conduct

[Bertrand Delacretaz]

Hi,

On Thu, Jul 2, 2015 at 6:05 PM, Pierre Smits  wrote:
> ...when at least one of its members in more than one occasion states that
> projects are independent (of the ASF) regarding how they conduct their
> business - except for the license aspect - it is rendered a paper tiger...

ASF projects are largely independent *when it comes to technical
matters*, but as far as governance there's a number of invariants that
are ASF-wide.

This code of conduct is one of those invariants.

-Bertrand

RE: Better specifying the scope of our Code of Conduct

[Ross Gardler (MS OPEN TECH)]

+1

You want an exec officer to be responsible for the CoC, it's the President.

Ross

-Original Message-
From: hedh...@gmail.com [mailto:hedh...@gmail.com] On Behalf Of Niclas Hedhman
Sent: Friday, July 3, 2015 12:14 AM
To: dev@community.apache.org
Subject: Re: Better specifying the scope of our Code of Conduct

As Jan is saying, this is simply not accurate.
"Official Policy" must be followed by all projects, and anyone can raise the 
concerns to various committees or board, when they think there is ongoing 
violation and no interest from a project to rectify it.


Legal Policy (which is not only that the project must use ALv2, but also about 
what can be dependent upon, how to package tarballs with LICENSE and NOTICE 
files, and policy around patents) is just one out of a handful policies that 
must be complied with, by ALL projects.
Branding and Code of Conduct are two other. How to package, sign, and 
distribute releases is another...

So, if "at least one of its members in more than one occasion states that 
projects are independent (of the ASF) regarding how they conduct their 
business" happens, then call that out for what it is...

Cheers
Niclas

On Thu, Jul 2, 2015 at 6:05 PM, Pierre Smits  wrote:

> It is a good thing that the board and the President regard the Code of 
> Conduct page as an official ASF policy and expect others to follow it, 
> but when at least one of its members in more than one occasion states 
> that projects are independent (of the ASF) regarding how they conduct 
> their business - except for the license aspect - it is rendered a paper 
> tiger...
>
> Having such an official ASF policy without the executing office 
> policing it, without podlings being required to accept and instill it 
> in their bylaws before graduation and allowing existing projects not 
> to incorporate it makes it nothing more than a hollow statement.
>
> Something to think about when making statement like these
>
> Best regards,
>
> Pierre Smits
>
> Op donderdag 2 juli 2015 heeft Shane Curcuru  
> het volgende geschreven:
>
> > On 6/30/15 2:04 PM, Rich Bowen wrote:
> > >
> > >
> > > On 06/30/2015 12:37 PM, Stefan Reich wrote:
> > >> I'm almost tired of criticizing so much, but... I think a "code 
> > >> of conduct"
> > >> is evil legalese and should be abandoned.
> > >>
> > >> Like Jesus said: "Love is the only law you need."
> > >
> > >
> > > Unfortunately, that hasn't worked out for us so far.
> >
> > More to the point, the board and the President have made it clear 
> > that the current CoC is an official ASF policy, so for interactions 
> > at ASF events or on our mailing lists, we expect people to follow it 
> > when working here on Apache projects.
> >
> > Obviously, other organizations or individuals can choose to use (or 
> > not) their own CoCs for their own projects, but this is the one 
> > we've chosen here.
> >
> > - Shane
> >
> > >
> > > A CoC serves several real needs. Publicly stating that we have 
> > > such an expectation makes the ASF more welcoming to joiners. It 
> > > also makes explicit some of the expectations for people who bull 
> > > through life without thinking about their interactions.
> > >
> > > Google for 'why we need a code of conduct' and then click on a 
> > > link at random and you'll get a more articulate statement of why 
> > > this is absolutely critical to an organization like ours that 
> > > spans cultures, timezones, projects, and many other borders.
> > >
> > > It is simply not the case that people just naturally know the 
> > > right way to behave. And it is the case that we need to have given 
> > > careful
> thought
> > > to what we're going to do about it when people are jerks.
> > >
> > > Even Jesus violently threw people out of the temple when they 
> > > broke the code of conduct.
> > >
> > > --Rich
> > >
> > >>
> > >> Cheers
> > >> Stefan
> > >>
> > >> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz 
> > >> 
> > >>> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Someone mentioned to me that they find the first paragraph of 
> > >>> http://www.apache.org/foundation/policies/conduct.html overly 
> > >>> broad, and I tend to agree.
> > >>>
> > >>> That paragraph says "this code of conduct governs how we behave 
> 

Re: Better specifying the scope of our Code of Conduct

[Niclas Hedhman]

As Jan is saying, this is simply not accurate.
"Official Policy" must be followed by all projects, and anyone can raise
the concerns to various committees or board, when they think there is
ongoing violation and no interest from a project to rectify it.


Legal Policy (which is not only that the project must use ALv2, but also
about what can be dependent upon, how to package tarballs with LICENSE and
NOTICE files, and policy around patents) is just one out of a handful
policies that must be complied with, by ALL projects.
Branding and Code of Conduct are two other. How to package, sign, and
distribute releases is another...

So, if "at least one of its members in more than one occasion states that
projects are independent (of the ASF) regarding how they conduct their
business" happens, then call that out for what it is...

Cheers
Niclas

On Thu, Jul 2, 2015 at 6:05 PM, Pierre Smits  wrote:

> It is a good thing that the board and the President regard the Code of
> Conduct page as an official ASF policy and expect others to follow it, but
> when at least one of its members in more than one occasion states that
> projects are independent (of the ASF) regarding how they conduct their
> business - except for the license aspect - it is rendered a paper tiger...
>
> Having such an official ASF policy without the executing office policing
> it, without podlings being required to accept and instill it in their
> bylaws before graduation and allowing existing projects not to incorporate
> it makes it nothing more than a hollow statement.
>
> Something to think about when making statement like these
>
> Best regards,
>
> Pierre Smits
>
> Op donderdag 2 juli 2015 heeft Shane Curcuru  het
> volgende geschreven:
>
> > On 6/30/15 2:04 PM, Rich Bowen wrote:
> > >
> > >
> > > On 06/30/2015 12:37 PM, Stefan Reich wrote:
> > >> I'm almost tired of criticizing so much, but... I think a "code of
> > >> conduct"
> > >> is evil legalese and should be abandoned.
> > >>
> > >> Like Jesus said: "Love is the only law you need."
> > >
> > >
> > > Unfortunately, that hasn't worked out for us so far.
> >
> > More to the point, the board and the President have made it clear that
> > the current CoC is an official ASF policy, so for interactions at ASF
> > events or on our mailing lists, we expect people to follow it when
> > working here on Apache projects.
> >
> > Obviously, other organizations or individuals can choose to use (or not)
> > their own CoCs for their own projects, but this is the one we've chosen
> > here.
> >
> > - Shane
> >
> > >
> > > A CoC serves several real needs. Publicly stating that we have such an
> > > expectation makes the ASF more welcoming to joiners. It also makes
> > > explicit some of the expectations for people who bull through life
> > > without thinking about their interactions.
> > >
> > > Google for 'why we need a code of conduct' and then click on a link at
> > > random and you'll get a more articulate statement of why this is
> > > absolutely critical to an organization like ours that spans cultures,
> > > timezones, projects, and many other borders.
> > >
> > > It is simply not the case that people just naturally know the right way
> > > to behave. And it is the case that we need to have given careful
> thought
> > > to what we're going to do about it when people are jerks.
> > >
> > > Even Jesus violently threw people out of the temple when they broke the
> > > code of conduct.
> > >
> > > --Rich
> > >
> > >>
> > >> Cheers
> > >> Stefan
> > >>
> > >> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
> > >> 
> > >>> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Someone mentioned to me that they find the first paragraph of
> > >>> http://www.apache.org/foundation/policies/conduct.html overly broad,
> > >>> and I tend to agree.
> > >>>
> > >>> That paragraph says "this code of conduct governs how we behave in
> any
> > >>> forum and whenever we will be judged by our actions" which implies
> > >>> that it also applies outside of "ASF territory" - I don't think
> that's
> > >>> appropriate. The next paragraph mentions "spaces managed by the
> Apache
> > >>> Software Foundation

Re: Better specifying the scope of our Code of Conduct

[jan i]

On 2 July 2015 at 18:05, Pierre Smits  wrote:

> It is a good thing that the board and the President regard the Code of
> Conduct page as an official ASF policy and expect others to follow it, but
> when at least one of its members in more than one occasion states that
> projects are independent (of the ASF) regarding how they conduct their
> business - except for the license aspect - it is rendered a paper tiger...
>

I think you are driving a simple statement far longer than intended. We do
not (luckily)  have many polices at ASF, but of course a project must
follow those.

A project can independent, make extra policies or even harden the ASF
policies (e.g. voting rules).

A project that act totally independent of ASF only following the license
rules,
cannot really be a ASF project.


> Having such an official ASF policy without the executing office policing
> it, without podlings being required to accept and instill it in their
> bylaws before graduation and allowing existing projects not to incorporate
> it makes it nothing more than a hollow statement,
>
Being part of IPMC, I thought it was part of the incubator to make sure that
exactly this happened.

I for one, does not see things as negative as you signal. Things can always
improve, but please not in the direction, that board installs a policy
police.

We, the committers, are those "controlling" that polices are kept,not the
board or any exec office.

just my opinion.
rgds
jan i.

>
> Something to think about when making statement like these
>
> Best regards,
>
> Pierre Smits
>
> Op donderdag 2 juli 2015 heeft Shane Curcuru  het
> volgende geschreven:
>
> > On 6/30/15 2:04 PM, Rich Bowen wrote:
> > >
> > >
> > > On 06/30/2015 12:37 PM, Stefan Reich wrote:
> > >> I'm almost tired of criticizing so much, but... I think a "code of
> > >> conduct"
> > >> is evil legalese and should be abandoned.
> > >>
> > >> Like Jesus said: "Love is the only law you need."
> > >
> > >
> > > Unfortunately, that hasn't worked out for us so far.
> >
> > More to the point, the board and the President have made it clear that
> > the current CoC is an official ASF policy, so for interactions at ASF
> > events or on our mailing lists, we expect people to follow it when
> > working here on Apache projects.
> >
> > Obviously, other organizations or individuals can choose to use (or not)
> > their own CoCs for their own projects, but this is the one we've chosen
> > here.
> >
> > - Shane
> >
> > >
> > > A CoC serves several real needs. Publicly stating that we have such an
> > > expectation makes the ASF more welcoming to joiners. It also makes
> > > explicit some of the expectations for people who bull through life
> > > without thinking about their interactions.
> > >
> > > Google for 'why we need a code of conduct' and then click on a link at
> > > random and you'll get a more articulate statement of why this is
> > > absolutely critical to an organization like ours that spans cultures,
> > > timezones, projects, and many other borders.
> > >
> > > It is simply not the case that people just naturally know the right way
> > > to behave. And it is the case that we need to have given careful
> thought
> > > to what we're going to do about it when people are jerks.
> > >
> > > Even Jesus violently threw people out of the temple when they broke the
> > > code of conduct.
> > >
> > > --Rich
> > >
> > >>
> > >> Cheers
> > >> Stefan
> > >>
> > >> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
> > >> 
> > >>> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Someone mentioned to me that they find the first paragraph of
> > >>> http://www.apache.org/foundation/policies/conduct.html overly broad,
> > >>> and I tend to agree.
> > >>>
> > >>> That paragraph says "this code of conduct governs how we behave in
> any
> > >>> forum and whenever we will be judged by our actions" which implies
> > >>> that it also applies outside of "ASF territory" - I don't think
> that's
> > >>> appropriate. The next paragraph mentions "spaces managed by the
> Apache
> > >>> Software Foundation" which I find much more appropriate, maybe
> > >>> expanded with "and whenever w

Re: Better specifying the scope of our Code of Conduct

[Pierre Smits]

It is a good thing that the board and the President regard the Code of
Conduct page as an official ASF policy and expect others to follow it, but
when at least one of its members in more than one occasion states that
projects are independent (of the ASF) regarding how they conduct their
business - except for the license aspect - it is rendered a paper tiger...

Having such an official ASF policy without the executing office policing
it, without podlings being required to accept and instill it in their
bylaws before graduation and allowing existing projects not to incorporate
it makes it nothing more than a hollow statement.

Something to think about when making statement like these

Best regards,

Pierre Smits

Op donderdag 2 juli 2015 heeft Shane Curcuru  het
volgende geschreven:

> On 6/30/15 2:04 PM, Rich Bowen wrote:
> >
> >
> > On 06/30/2015 12:37 PM, Stefan Reich wrote:
> >> I'm almost tired of criticizing so much, but... I think a "code of
> >> conduct"
> >> is evil legalese and should be abandoned.
> >>
> >> Like Jesus said: "Love is the only law you need."
> >
> >
> > Unfortunately, that hasn't worked out for us so far.
>
> More to the point, the board and the President have made it clear that
> the current CoC is an official ASF policy, so for interactions at ASF
> events or on our mailing lists, we expect people to follow it when
> working here on Apache projects.
>
> Obviously, other organizations or individuals can choose to use (or not)
> their own CoCs for their own projects, but this is the one we've chosen
> here.
>
> - Shane
>
> >
> > A CoC serves several real needs. Publicly stating that we have such an
> > expectation makes the ASF more welcoming to joiners. It also makes
> > explicit some of the expectations for people who bull through life
> > without thinking about their interactions.
> >
> > Google for 'why we need a code of conduct' and then click on a link at
> > random and you'll get a more articulate statement of why this is
> > absolutely critical to an organization like ours that spans cultures,
> > timezones, projects, and many other borders.
> >
> > It is simply not the case that people just naturally know the right way
> > to behave. And it is the case that we need to have given careful thought
> > to what we're going to do about it when people are jerks.
> >
> > Even Jesus violently threw people out of the temple when they broke the
> > code of conduct.
> >
> > --Rich
> >
> >>
> >> Cheers
> >> Stefan
> >>
> >> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
> >> 
> >>> wrote:
> >>
> >>> Hi,
> >>>
> >>> Someone mentioned to me that they find the first paragraph of
> >>> http://www.apache.org/foundation/policies/conduct.html overly broad,
> >>> and I tend to agree.
> >>>
> >>> That paragraph says "this code of conduct governs how we behave in any
> >>> forum and whenever we will be judged by our actions" which implies
> >>> that it also applies outside of "ASF territory" - I don't think that's
> >>> appropriate. The next paragraph mentions "spaces managed by the Apache
> >>> Software Foundation" which I find much more appropriate, maybe
> >>> expanded with "and whenever we represent the ASF".
> >>>
> >>> The reasoning is that we can only speak about our own territory.
> >>>
> >>> As a simple example, putting your hand on someone's shoulder while
> >>> talking to them is totally welcome in some cultures while considered
> >>> "unwelcome sexual attention" (to reuse the words of that document) in
> >>> others. We might ask people to refrain from doing that in our
> >>> multi-cultural environment where we need to go down to some common
> >>> denominator of acceptable behavior, but we can't blame them for doing
> >>> that where it's culturally acceptable and even expected. The same goes
> >>> with profanity, where the acceptable level varies immensely between
> >>> cultures.
> >>>
> >>> So I think it's good to restrict our code of conduct to our own
> >>> territory.
> >>>
> >>> I suggest reworking the first few paragraphs as follows, to clarify
> >>> that:
> >>>
> >>> *** reworked code of conduct intro section ***
> >>> This code o

Re: Better specifying the scope of our Code of Conduct

[Shane Curcuru]

On 6/30/15 2:04 PM, Rich Bowen wrote:
> 
> 
> On 06/30/2015 12:37 PM, Stefan Reich wrote:
>> I'm almost tired of criticizing so much, but... I think a "code of
>> conduct"
>> is evil legalese and should be abandoned.
>>
>> Like Jesus said: "Love is the only law you need."
> 
> 
> Unfortunately, that hasn't worked out for us so far.

More to the point, the board and the President have made it clear that
the current CoC is an official ASF policy, so for interactions at ASF
events or on our mailing lists, we expect people to follow it when
working here on Apache projects.

Obviously, other organizations or individuals can choose to use (or not)
their own CoCs for their own projects, but this is the one we've chosen
here.

- Shane

> 
> A CoC serves several real needs. Publicly stating that we have such an
> expectation makes the ASF more welcoming to joiners. It also makes
> explicit some of the expectations for people who bull through life
> without thinking about their interactions.
> 
> Google for 'why we need a code of conduct' and then click on a link at
> random and you'll get a more articulate statement of why this is
> absolutely critical to an organization like ours that spans cultures,
> timezones, projects, and many other borders.
> 
> It is simply not the case that people just naturally know the right way
> to behave. And it is the case that we need to have given careful thought
> to what we're going to do about it when people are jerks.
> 
> Even Jesus violently threw people out of the temple when they broke the
> code of conduct.
> 
> --Rich
> 
>>
>> Cheers
>> Stefan
>>
>> On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz
>> >> wrote:
>>
>>> Hi,
>>>
>>> Someone mentioned to me that they find the first paragraph of
>>> http://www.apache.org/foundation/policies/conduct.html overly broad,
>>> and I tend to agree.
>>>
>>> That paragraph says "this code of conduct governs how we behave in any
>>> forum and whenever we will be judged by our actions" which implies
>>> that it also applies outside of "ASF territory" - I don't think that's
>>> appropriate. The next paragraph mentions "spaces managed by the Apache
>>> Software Foundation" which I find much more appropriate, maybe
>>> expanded with "and whenever we represent the ASF".
>>>
>>> The reasoning is that we can only speak about our own territory.
>>>
>>> As a simple example, putting your hand on someone's shoulder while
>>> talking to them is totally welcome in some cultures while considered
>>> "unwelcome sexual attention" (to reuse the words of that document) in
>>> others. We might ask people to refrain from doing that in our
>>> multi-cultural environment where we need to go down to some common
>>> denominator of acceptable behavior, but we can't blame them for doing
>>> that where it's culturally acceptable and even expected. The same goes
>>> with profanity, where the acceptable level varies immensely between
>>> cultures.
>>>
>>> So I think it's good to restrict our code of conduct to our own
>>> territory.
>>>
>>> I suggest reworking the first few paragraphs as follows, to clarify
>>> that:
>>>
>>> *** reworked code of conduct intro section ***
>>> This code of conduct applies to all spaces managed by the Apache
>>> Software Foundation, including IRC, all public and private mailing
>>> lists, issue trackers, wikis, blogs, Twitter, and any other
>>> communication channel used by our communities. A code of conduct which
>>> is specific to in-person events (ie., conferences) is codified in the
>>> published ASF anti-harassment policy.
>>>
>>> We expect this code of conduct to be honored by everyone who
>>> participates in the Apache community formally or informally, or claims
>>> any affiliation with the Foundation, in any Foundation-related
>>> activities and especially when representing the ASF, in any role.
>>>
>>> This code is not exhaustive or complete(unchanged from here on)
>>> *** reworked code of conduct intro section ***
>>>
>>> What do people think?
>>> -Bertrand
>>>
>>
> 
> 

Re: Better specifying the scope of our Code of Conduct

[Bkrm Adhikari]

Yes sure i...do

Rich Bowen  wrote:

>
>
>On 06/30/2015 07:23 AM, jan i wrote:
>> Maybe I am a bad reader, but I read it as apacheCON CORE is not covered and
>> surely apache big data
>> (which is a "pure" LF managed event), because the space is managed by LF. I
>> would like to see it "applied to"
>> and not only "expect to be honered" for  all apache events including
>> apacheCON.
>
>
>LF has a code of conduct. It's shorter than ours, and probably more 
>easily enforceable because it covers a very limited time and space, 
>whereas ours covers the known universe and all time.
>
>If someone behaves badly at ApacheCon, we (actually, LF) can throw them 
>out the door and ask them not to come back next time.
>
>If someone behaves badly at the ASF, how do we enforce? This is yet to 
>be determined.
>
>If you wish to apply our CoC to ApacheCon, we need to be very clear with 
>LF as to what that means, specifically, and we also need to take 
>responsibility for that enforcement. As it stands now, we rely on LF to 
>enforce their CoC, when we report incidents to them. I'm not actually 
>sure we want to take that over from them, but it's certainly worth 
>discussing.
>
>
>-- 
>Rich Bowen - rbo...@rcbowen.com - @rbowen
>http://apachecon.com/ - @apachecon

Re: Better specifying the scope of our Code of Conduct

[Rich Bowen]

On 06/30/2015 12:37 PM, Stefan Reich wrote:

I'm almost tired of criticizing so much, but... I think a "code of conduct"
is evil legalese and should be abandoned.

Like Jesus said: "Love is the only law you need."



Unfortunately, that hasn't worked out for us so far.

A CoC serves several real needs. Publicly stating that we have such an 
expectation makes the ASF more welcoming to joiners. It also makes 
explicit some of the expectations for people who bull through life 
without thinking about their interactions.


Google for 'why we need a code of conduct' and then click on a link at 
random and you'll get a more articulate statement of why this is 
absolutely critical to an organization like ours that spans cultures, 
timezones, projects, and many other borders.


It is simply not the case that people just naturally know the right way 
to behave. And it is the case that we need to have given careful thought 
to what we're going to do about it when people are jerks.


Even Jesus violently threw people out of the temple when they broke the 
code of conduct.


--Rich



Cheers
Stefan

On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz 
wrote:



Hi,

Someone mentioned to me that they find the first paragraph of
http://www.apache.org/foundation/policies/conduct.html overly broad,
and I tend to agree.

That paragraph says "this code of conduct governs how we behave in any
forum and whenever we will be judged by our actions" which implies
that it also applies outside of "ASF territory" - I don't think that's
appropriate. The next paragraph mentions "spaces managed by the Apache
Software Foundation" which I find much more appropriate, maybe
expanded with "and whenever we represent the ASF".

The reasoning is that we can only speak about our own territory.

As a simple example, putting your hand on someone's shoulder while
talking to them is totally welcome in some cultures while considered
"unwelcome sexual attention" (to reuse the words of that document) in
others. We might ask people to refrain from doing that in our
multi-cultural environment where we need to go down to some common
denominator of acceptable behavior, but we can't blame them for doing
that where it's culturally acceptable and even expected. The same goes
with profanity, where the acceptable level varies immensely between
cultures.

So I think it's good to restrict our code of conduct to our own territory.

I suggest reworking the first few paragraphs as follows, to clarify that:

*** reworked code of conduct intro section ***
This code of conduct applies to all spaces managed by the Apache
Software Foundation, including IRC, all public and private mailing
lists, issue trackers, wikis, blogs, Twitter, and any other
communication channel used by our communities. A code of conduct which
is specific to in-person events (ie., conferences) is codified in the
published ASF anti-harassment policy.

We expect this code of conduct to be honored by everyone who
participates in the Apache community formally or informally, or claims
any affiliation with the Foundation, in any Foundation-related
activities and especially when representing the ASF, in any role.

This code is not exhaustive or complete(unchanged from here on)
*** reworked code of conduct intro section ***

What do people think?
-Bertrand






--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Better specifying the scope of our Code of Conduct

[Rich Bowen]

On 06/30/2015 07:23 AM, jan i wrote:

Maybe I am a bad reader, but I read it as apacheCON CORE is not covered and
surely apache big data
(which is a "pure" LF managed event), because the space is managed by LF. I
would like to see it "applied to"
and not only "expect to be honered" for  all apache events including
apacheCON.



LF has a code of conduct. It's shorter than ours, and probably more 
easily enforceable because it covers a very limited time and space, 
whereas ours covers the known universe and all time.


If someone behaves badly at ApacheCon, we (actually, LF) can throw them 
out the door and ask them not to come back next time.


If someone behaves badly at the ASF, how do we enforce? This is yet to 
be determined.


If you wish to apply our CoC to ApacheCon, we need to be very clear with 
LF as to what that means, specifically, and we also need to take 
responsibility for that enforcement. As it stands now, we rely on LF to 
enforce their CoC, when we report incidents to them. I'm not actually 
sure we want to take that over from them, but it's certainly worth 
discussing.



--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Better specifying the scope of our Code of Conduct

[Stefan Reich]

I'm almost tired of criticizing so much, but... I think a "code of conduct"
is evil legalese and should be abandoned.

Like Jesus said: "Love is the only law you need."

Cheers
Stefan

On Tue, Jun 30, 2015 at 1:01 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> Someone mentioned to me that they find the first paragraph of
> http://www.apache.org/foundation/policies/conduct.html overly broad,
> and I tend to agree.
>
> That paragraph says "this code of conduct governs how we behave in any
> forum and whenever we will be judged by our actions" which implies
> that it also applies outside of "ASF territory" - I don't think that's
> appropriate. The next paragraph mentions "spaces managed by the Apache
> Software Foundation" which I find much more appropriate, maybe
> expanded with "and whenever we represent the ASF".
>
> The reasoning is that we can only speak about our own territory.
>
> As a simple example, putting your hand on someone's shoulder while
> talking to them is totally welcome in some cultures while considered
> "unwelcome sexual attention" (to reuse the words of that document) in
> others. We might ask people to refrain from doing that in our
> multi-cultural environment where we need to go down to some common
> denominator of acceptable behavior, but we can't blame them for doing
> that where it's culturally acceptable and even expected. The same goes
> with profanity, where the acceptable level varies immensely between
> cultures.
>
> So I think it's good to restrict our code of conduct to our own territory.
>
> I suggest reworking the first few paragraphs as follows, to clarify that:
>
> *** reworked code of conduct intro section ***
> This code of conduct applies to all spaces managed by the Apache
> Software Foundation, including IRC, all public and private mailing
> lists, issue trackers, wikis, blogs, Twitter, and any other
> communication channel used by our communities. A code of conduct which
> is specific to in-person events (ie., conferences) is codified in the
> published ASF anti-harassment policy.
>
> We expect this code of conduct to be honored by everyone who
> participates in the Apache community formally or informally, or claims
> any affiliation with the Foundation, in any Foundation-related
> activities and especially when representing the ASF, in any role.
>
> This code is not exhaustive or complete(unchanged from here on)
> *** reworked code of conduct intro section ***
>
> What do people think?
> -Bertrand
>

Re: Better specifying the scope of our Code of Conduct

[jan i]

On Tuesday, June 30, 2015, Bertrand Delacretaz 
wrote:

> Hi,
>
> On Tue, Jun 30, 2015 at 1:23 PM, jan i >
> wrote:
> > ...I read it as apacheCON CORE is not covered and
> > surely apache big data
> > (which is a "pure" LF managed event), because the space is managed by
> LF...
>
> It says "A code of conduct which is specific to in-person events (ie.,
> conferences) is codified in the published ASF anti-harassment policy."
> which refers to
> http://www.apache.org/foundation/policies/anti-harassment.html
>
> Does that work for you?

+1

rgds
jan i

>
> -Bertrand
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: Better specifying the scope of our Code of Conduct

[Bertrand Delacretaz]

Hi,

On Tue, Jun 30, 2015 at 1:23 PM, jan i  wrote:
> ...I read it as apacheCON CORE is not covered and
> surely apache big data
> (which is a "pure" LF managed event), because the space is managed by LF...

It says "A code of conduct which is specific to in-person events (ie.,
conferences) is codified in the published ASF anti-harassment policy."
which refers to
http://www.apache.org/foundation/policies/anti-harassment.html

Does that work for you?

-Bertrand

Re: Better specifying the scope of our Code of Conduct

[Christopher]

+1

On Tue, Jun 30, 2015, 07:01 Bertrand Delacretaz 
wrote:

> Hi,
>
> Someone mentioned to me that they find the first paragraph of
> http://www.apache.org/foundation/policies/conduct.html overly broad,
> and I tend to agree.
>
> That paragraph says "this code of conduct governs how we behave in any
> forum and whenever we will be judged by our actions" which implies
> that it also applies outside of "ASF territory" - I don't think that's
> appropriate. The next paragraph mentions "spaces managed by the Apache
> Software Foundation" which I find much more appropriate, maybe
> expanded with "and whenever we represent the ASF".
>
> The reasoning is that we can only speak about our own territory.
>
> As a simple example, putting your hand on someone's shoulder while
> talking to them is totally welcome in some cultures while considered
> "unwelcome sexual attention" (to reuse the words of that document) in
> others. We might ask people to refrain from doing that in our
> multi-cultural environment where we need to go down to some common
> denominator of acceptable behavior, but we can't blame them for doing
> that where it's culturally acceptable and even expected. The same goes
> with profanity, where the acceptable level varies immensely between
> cultures.
>
> So I think it's good to restrict our code of conduct to our own territory.
>
> I suggest reworking the first few paragraphs as follows, to clarify that:
>
> *** reworked code of conduct intro section ***
> This code of conduct applies to all spaces managed by the Apache
> Software Foundation, including IRC, all public and private mailing
> lists, issue trackers, wikis, blogs, Twitter, and any other
> communication channel used by our communities. A code of conduct which
> is specific to in-person events (ie., conferences) is codified in the
> published ASF anti-harassment policy.
>
> We expect this code of conduct to be honored by everyone who
> participates in the Apache community formally or informally, or claims
> any affiliation with the Foundation, in any Foundation-related
> activities and especially when representing the ASF, in any role.
>
> This code is not exhaustive or complete(unchanged from here on)
> *** reworked code of conduct intro section ***
>
> What do people think?
> -Bertrand
>

Re: Better specifying the scope of our Code of Conduct

[jan i]

On 30 June 2015 at 13:01, Bertrand Delacretaz 
wrote:

> Hi,
>
> Someone mentioned to me that they find the first paragraph of
> http://www.apache.org/foundation/policies/conduct.html overly broad,
> and I tend to agree.
>
> That paragraph says "this code of conduct governs how we behave in any
> forum and whenever we will be judged by our actions" which implies
> that it also applies outside of "ASF territory" - I don't think that's
> appropriate. The next paragraph mentions "spaces managed by the Apache
> Software Foundation" which I find much more appropriate, maybe
> expanded with "and whenever we represent the ASF".
>
> The reasoning is that we can only speak about our own territory.
>
> As a simple example, putting your hand on someone's shoulder while
> talking to them is totally welcome in some cultures while considered
> "unwelcome sexual attention" (to reuse the words of that document) in
> others. We might ask people to refrain from doing that in our
> multi-cultural environment where we need to go down to some common
> denominator of acceptable behavior, but we can't blame them for doing
> that where it's culturally acceptable and even expected. The same goes
> with profanity, where the acceptable level varies immensely between
> cultures.
>
> So I think it's good to restrict our code of conduct to our own territory.
>
> I suggest reworking the first few paragraphs as follows, to clarify that:
>
> *** reworked code of conduct intro section ***
> This code of conduct applies to all spaces managed by the Apache
> Software Foundation, including IRC, all public and private mailing
> lists, issue trackers, wikis, blogs, Twitter, and any other
> communication channel used by our communities. A code of conduct which
> is specific to in-person events (ie., conferences) is codified in the
> published ASF anti-harassment policy.
>
> We expect this code of conduct to be honored by everyone who
> participates in the Apache community formally or informally, or claims
> any affiliation with the Foundation, in any Foundation-related
> activities and especially when representing the ASF, in any role.
>
> This code is not exhaustive or complete(unchanged from here on)
> *** reworked code of conduct intro section ***
>
> What do people think?
>
Maybe I am a bad reader, but I read it as apacheCON CORE is not covered and
surely apache big data
(which is a "pure" LF managed event), because the space is managed by LF. I
would like to see it "applied to"
and not only "expect to be honered" for  all apache events including
apacheCON.

rgds
jan i.


> -Bertrand
>

Better specifying the scope of our Code of Conduct

[Bertrand Delacretaz]

Hi,

Someone mentioned to me that they find the first paragraph of
http://www.apache.org/foundation/policies/conduct.html overly broad,
and I tend to agree.

That paragraph says "this code of conduct governs how we behave in any
forum and whenever we will be judged by our actions" which implies
that it also applies outside of "ASF territory" - I don't think that's
appropriate. The next paragraph mentions "spaces managed by the Apache
Software Foundation" which I find much more appropriate, maybe
expanded with "and whenever we represent the ASF".

The reasoning is that we can only speak about our own territory.

As a simple example, putting your hand on someone's shoulder while
talking to them is totally welcome in some cultures while considered
"unwelcome sexual attention" (to reuse the words of that document) in
others. We might ask people to refrain from doing that in our
multi-cultural environment where we need to go down to some common
denominator of acceptable behavior, but we can't blame them for doing
that where it's culturally acceptable and even expected. The same goes
with profanity, where the acceptable level varies immensely between
cultures.

So I think it's good to restrict our code of conduct to our own territory.

I suggest reworking the first few paragraphs as follows, to clarify that:

*** reworked code of conduct intro section ***
This code of conduct applies to all spaces managed by the Apache
Software Foundation, including IRC, all public and private mailing
lists, issue trackers, wikis, blogs, Twitter, and any other
communication channel used by our communities. A code of conduct which
is specific to in-person events (ie., conferences) is codified in the
published ASF anti-harassment policy.

We expect this code of conduct to be honored by everyone who
participates in the Apache community formally or informally, or claims
any affiliation with the Foundation, in any Foundation-related
activities and especially when representing the ASF, in any role.

This code is not exhaustive or complete(unchanged from here on)
*** reworked code of conduct intro section ***

What do people think?
-Bertrand

Re: Code of Conduct - links to why they are needed etc

[Shane Curcuru]

On 3/26/15 1:46 PM, Noah Slater wrote:
> Oh, thanks for the input Shane!
> 
> I don't want to make the punitive measures stuff too complex. It should be
> simple and easy to understand for both those who want protection from
> harassment and so on, and those who've been spoken to about adjusting their
> conduct.
> 
> A strikes system is one idea. So individuals get warnings for minor things,
> and are told to adjust.
> 
> Beyond that, we might consider several things:
> 
> - Temporary removal from a mailing list (or whether the behaviour is
> occurring)
> - Longer periods of removal or banning from the same

I would expect both of the above every PMC could/should do for
themselves.  I.e. the PMC and private@ should be the reporting path, and
the PMC can just do the above as they see the need.

Importantly, I think most people would look to PMCs to document their
own systems.  Having an ASF-wide "sample policy" would be good, but I'm
betting some PMCs would still use their own details

> - Removal from a PMC, or revocation of committer or member status

PMCs should be able to remove their own committers, although one would
hope that is rare.  Anything dealing with removing or otherwise
censuring PMC members or ASF Members would need to be done by the board.


> People should know that we are perfectly prepared to expel individuals from
> our community who do not work with us to keep it a safe and welcoming
> environment for everybody.

"Our community" also points to setting the expectation that the group
closest to the community should be enforcing these - hence, the PMCs
whenever possible should police their own projects.


> 
> Removing from PMC and revocation of committer status can be done by PMCs
> themselves, should they be the ones enforcing the CoC. If not that, a
> recommendation from the Community PMC to the board to take the appropriate
> action. And failing that, for the Board itself to step in and take such
> action.

Yup.

- Shane


> 
> 
> On Wed, 25 Mar 2015 at 18:20 Shane Curcuru  wrote:
> 
>> On 3/25/15 12:00 PM, Noah Slater wrote:
>>> Yep, thanks for the reply. I'm not sure how to handle the governance side
>>> of this. But I'm sure we can come to an agreement on this list soon.
>>
>> Discussing here makes sense; it's public and there are plenty of helpful
>> voices that are likely to participate; plus this is a key thing we
>> should ensure that newcomers to our communities see.  This group should
>> definitely be able to get consensus on any updates and be able to
>> publish them - if board or President have issues, I'm sure they'll
>> weight in about the documentation if needed.
>>
>> In terms of escalation and reporting, that's tricky, because we are both
>> a Delaware corporation and a volunteer-run community.
>>
>> - For issues within one project, the best first place to escalate is
>> that PMC's private@ list, if the reporter is comfortable doing so.
>>
>> - Otherwise, I'd say the private@community.a.o list would be an
>> effective place to report/escalate, because there are people here who
>> could help working within the community.
>>
>> - Beyond that, we need board or President to agree on whatever further
>> "formal" contact address or escalation path we will support.  Barring
>> anything more specific, I'd start the recommendation being board@.
>>
>> In terms of enforcement, there are plenty of different people
>> (especially Members) at the ASF who can help with enforcement on a
>> community scale, so any ways we can make it more obvious for how to
>> contact them/ask for help is good.
>>
>> But in terms of true enforcement, that goes to the board.  Since PMCs
>> report to the board, it's up to the board to enforce any serious issues,
>> if it comes to that.  Specific issues with infra/press/brand, and
>> probably conferences (i.e. not issues within an Apache project) should
>> escalate to President@, because those officers report to the President.
>>
>> - Shane
>>
>> P.S. This is a good topic - reminds me of a question recently on
>> foundations list elsewhere asking what mediation/personnel issue
>> reporting policies that different Foundations have (or not have).
>>
>>
> 

Re: Code of Conduct - links to why they are needed etc

[Noah Slater]

*or where ever

On Thu, 26 Mar 2015 at 18:46 Noah Slater  wrote:

> Oh, thanks for the input Shane!
>
> I don't want to make the punitive measures stuff too complex. It should be
> simple and easy to understand for both those who want protection from
> harassment and so on, and those who've been spoken to about adjusting their
> conduct.
>
> A strikes system is one idea. So individuals get warnings for minor
> things, and are told to adjust.
>
> Beyond that, we might consider several things:
>
> - Temporary removal from a mailing list (or whether the behaviour is
> occurring)
> - Longer periods of removal or banning from the same
> - Removal from a PMC, or revocation of committer or member status
>
> People should know that we are perfectly prepared to expel individuals
> from our community who do not work with us to keep it a safe and welcoming
> environment for everybody.
>
> Removing from PMC and revocation of committer status can be done by PMCs
> themselves, should they be the ones enforcing the CoC. If not that, a
> recommendation from the Community PMC to the board to take the appropriate
> action. And failing that, for the Board itself to step in and take such
> action.
>
>
> On Wed, 25 Mar 2015 at 18:20 Shane Curcuru  wrote:
>
>> On 3/25/15 12:00 PM, Noah Slater wrote:
>> > Yep, thanks for the reply. I'm not sure how to handle the governance
>> side
>> > of this. But I'm sure we can come to an agreement on this list soon.
>>
>> Discussing here makes sense; it's public and there are plenty of helpful
>> voices that are likely to participate; plus this is a key thing we
>> should ensure that newcomers to our communities see.  This group should
>> definitely be able to get consensus on any updates and be able to
>> publish them - if board or President have issues, I'm sure they'll
>> weight in about the documentation if needed.
>>
>> In terms of escalation and reporting, that's tricky, because we are both
>> a Delaware corporation and a volunteer-run community.
>>
>> - For issues within one project, the best first place to escalate is
>> that PMC's private@ list, if the reporter is comfortable doing so.
>>
>> - Otherwise, I'd say the private@community.a.o list would be an
>> effective place to report/escalate, because there are people here who
>> could help working within the community.
>>
>> - Beyond that, we need board or President to agree on whatever further
>> "formal" contact address or escalation path we will support.  Barring
>> anything more specific, I'd start the recommendation being board@.
>>
>> In terms of enforcement, there are plenty of different people
>> (especially Members) at the ASF who can help with enforcement on a
>> community scale, so any ways we can make it more obvious for how to
>> contact them/ask for help is good.
>>
>> But in terms of true enforcement, that goes to the board.  Since PMCs
>> report to the board, it's up to the board to enforce any serious issues,
>> if it comes to that.  Specific issues with infra/press/brand, and
>> probably conferences (i.e. not issues within an Apache project) should
>> escalate to President@, because those officers report to the President.
>>
>> - Shane
>>
>> P.S. This is a good topic - reminds me of a question recently on
>> foundations list elsewhere asking what mediation/personnel issue
>> reporting policies that different Foundations have (or not have).
>>
>>

Re: Code of Conduct - links to why they are needed etc

[Noah Slater]

Oh, thanks for the input Shane!

I don't want to make the punitive measures stuff too complex. It should be
simple and easy to understand for both those who want protection from
harassment and so on, and those who've been spoken to about adjusting their
conduct.

A strikes system is one idea. So individuals get warnings for minor things,
and are told to adjust.

Beyond that, we might consider several things:

- Temporary removal from a mailing list (or whether the behaviour is
occurring)
- Longer periods of removal or banning from the same
- Removal from a PMC, or revocation of committer or member status

People should know that we are perfectly prepared to expel individuals from
our community who do not work with us to keep it a safe and welcoming
environment for everybody.

Removing from PMC and revocation of committer status can be done by PMCs
themselves, should they be the ones enforcing the CoC. If not that, a
recommendation from the Community PMC to the board to take the appropriate
action. And failing that, for the Board itself to step in and take such
action.


On Wed, 25 Mar 2015 at 18:20 Shane Curcuru  wrote:

> On 3/25/15 12:00 PM, Noah Slater wrote:
> > Yep, thanks for the reply. I'm not sure how to handle the governance side
> > of this. But I'm sure we can come to an agreement on this list soon.
>
> Discussing here makes sense; it's public and there are plenty of helpful
> voices that are likely to participate; plus this is a key thing we
> should ensure that newcomers to our communities see.  This group should
> definitely be able to get consensus on any updates and be able to
> publish them - if board or President have issues, I'm sure they'll
> weight in about the documentation if needed.
>
> In terms of escalation and reporting, that's tricky, because we are both
> a Delaware corporation and a volunteer-run community.
>
> - For issues within one project, the best first place to escalate is
> that PMC's private@ list, if the reporter is comfortable doing so.
>
> - Otherwise, I'd say the private@community.a.o list would be an
> effective place to report/escalate, because there are people here who
> could help working within the community.
>
> - Beyond that, we need board or President to agree on whatever further
> "formal" contact address or escalation path we will support.  Barring
> anything more specific, I'd start the recommendation being board@.
>
> In terms of enforcement, there are plenty of different people
> (especially Members) at the ASF who can help with enforcement on a
> community scale, so any ways we can make it more obvious for how to
> contact them/ask for help is good.
>
> But in terms of true enforcement, that goes to the board.  Since PMCs
> report to the board, it's up to the board to enforce any serious issues,
> if it comes to that.  Specific issues with infra/press/brand, and
> probably conferences (i.e. not issues within an Apache project) should
> escalate to President@, because those officers report to the President.
>
> - Shane
>
> P.S. This is a good topic - reminds me of a question recently on
> foundations list elsewhere asking what mediation/personnel issue
> reporting policies that different Foundations have (or not have).
>
>

Re: Code of Conduct - links to why they are needed etc

[Shane Curcuru]

On 3/25/15 12:00 PM, Noah Slater wrote:
> Yep, thanks for the reply. I'm not sure how to handle the governance side
> of this. But I'm sure we can come to an agreement on this list soon.

Discussing here makes sense; it's public and there are plenty of helpful
voices that are likely to participate; plus this is a key thing we
should ensure that newcomers to our communities see.  This group should
definitely be able to get consensus on any updates and be able to
publish them - if board or President have issues, I'm sure they'll
weight in about the documentation if needed.

In terms of escalation and reporting, that's tricky, because we are both
a Delaware corporation and a volunteer-run community.

- For issues within one project, the best first place to escalate is
that PMC's private@ list, if the reporter is comfortable doing so.

- Otherwise, I'd say the private@community.a.o list would be an
effective place to report/escalate, because there are people here who
could help working within the community.

- Beyond that, we need board or President to agree on whatever further
"formal" contact address or escalation path we will support.  Barring
anything more specific, I'd start the recommendation being board@.

In terms of enforcement, there are plenty of different people
(especially Members) at the ASF who can help with enforcement on a
community scale, so any ways we can make it more obvious for how to
contact them/ask for help is good.

But in terms of true enforcement, that goes to the board.  Since PMCs
report to the board, it's up to the board to enforce any serious issues,
if it comes to that.  Specific issues with infra/press/brand, and
probably conferences (i.e. not issues within an Apache project) should
escalate to President@, because those officers report to the President.

- Shane

P.S. This is a good topic - reminds me of a question recently on
foundations list elsewhere asking what mediation/personnel issue
reporting policies that different Foundations have (or not have).

Re: Code of Conduct - links to why they are needed etc

[Noah Slater]

Yep, thanks for the reply. I'm not sure how to handle the governance side
of this. But I'm sure we can come to an agreement on this list soon.

On Wed, 25 Mar 2015 at 15:13 jan i  wrote:

> On 25 March 2015 at 13:08, Noah Slater  wrote:
>
> > Jan,
> >
> > Late to the party here, sorry. But I wanna reply to your point that the
> CoC
> > is not meant to be enforceable.
> >
> > That is not the case, as I understand it. Indeed, an unenforceable or
> > not-regularly-enforced CoC is not worthless, it's actually *harmful* and
> > dangerous for marginalised people in our community. Because we are
> > communicating to them that we have certain standards, and then not taking
> > any action to make sure that those standards are met.
> >
>
> Maybe I should have spent more words. Of course there are CoC items that
> should and  can be enforced, but to me there
> are also some with quite some elastic built in. For example we have a CoC
> for email, do not use he/she and be polite. The first
> part is easy to enforce, but the second part ? what you see as polite might
> not be polite to me.
>
>
> >
> > A community is, in many ways, defined by whatever its leaders are
> prepared
> > to tolerate. Our CoC is, and should continue to be, a document that
> > outlines what we do not tolerate. And for that to mean anything, we need
> to
> > put our money where our mouth is and enforce it.
> >
> I agree the CoC needs to contain what is not to be tolerated and will be
> enforced. But may the rest is CoC good practice, which
> to me is just as important for new people.
>
>
> >
> > And this shouldn't be optional for podlings or projects. This should
> apply
> > across the board, for the whole org, like the foundation's bylaws
> > themselves. Or again, it is useless.
> >
> > To make that work, we need to add three things:
> >
> > 1. A clear way for the document to be updated. We have a model on CouchDB
> > (which is where the doc came from) and we can simply port that the
> > Community PMC, where people can come to discuss changes.
> >
> +1
>
> >
> > 2. We need a foundation-level reporting mechanism (again, presumably
> > coordinating this through the Community PMC)
> >
> I would not like the community PMC to become judges or police, ideally the
> PMC should deal with it, and if they fail
> we need an escalation mechanism.
>
>
> >
> > 3. We need clearly defined enforcement guidelines or punitive measures,
> so
> > that people know what action will be taken, and when
> >
> +1
>
> I hope that made my point a bit clearer, I do not think we disagree as
> such.
>
> rgds
> jan i.
>
>
> >
> > On Sat, 20 Dec 2014 at 21:14 jan i  wrote:
> >
> > > On 20 December 2014 at 20:55, Louis Suárez-Potts 
> > wrote:
> > >
> > > > Hi,
> > > > > On 20 Dec 2014, at 09:50, Jim Jagielski  wrote:
> > > > >
> > > > > This is great and, as noted, long overdue. Although the code
> > > > > itself "simply" codifies what had been the tribal knowledge
> > > > > of the ASF, and how we'd expected people to behave, NOT having
> > > > > it written down was pretty sad.
> > > > >
> > > > > Thx to all for making it happen.
> > > > >
> > > > >> On Dec 20, 2014, at 6:33 AM, sebb  wrote:
> > > > >>
> > > > >> There are some useful links in the CoC blog:
> > > > >>
> > > > >>
> > > > https://blogs.apache.org/foundation/entry/asf_
> > > publishes_long_overdue_code
> > > > >>
> > > > >> For example,
> > > > >> Ashe Dryden's introductory resource for learning more about how
> > Codes
> > > > >> of Conduct can help
> > > > >>
> > > > >> Perhaps these should be added to the ASF CoC page at
> > > > >>
> > > > >> http://www.apache.org/foundation/policies/conduct.html
> > > > >
> > > >
> > > > So, now that it is written down—great—does this mean then that we
> will
> > be
> > > > asking all new projects (and podlings and everything else) to
> > > obligatorily
> > > > review it? As part of the Apache Way? That is, what is the
> relationship
> > > > between this CoC and the Apache Way from the perspective of the new
> > > member
> > > > to Apache?
> > > >
> > >
> > > maybe I see it wrong, but to me a "code of conduct" is more a guideline
> > > than an actual rulebook. It is a description of how we would like to
> > > interact with other, and therefore not something that should be used as
> > > "you did not follow the code of conduct, so now I take action".
> > >
> > > I think it is important to see both the "apache way" and "code of
> > conduct"
> > > as guidelines, not something formulated by lawyers to stand up in
> court.
> > >
> > > So in essence we should all be aware of what the intention is and that
> > > includes podlings coming to apache.
> > >
> > > rgds
> > > jan i.
> > >
> > >
> > > > Louis
> > > >
> > > >
> > >
> >
>

Re: Code of Conduct - links to why they are needed etc

[jan i]

On 25 March 2015 at 13:08, Noah Slater  wrote:

> Jan,
>
> Late to the party here, sorry. But I wanna reply to your point that the CoC
> is not meant to be enforceable.
>
> That is not the case, as I understand it. Indeed, an unenforceable or
> not-regularly-enforced CoC is not worthless, it's actually *harmful* and
> dangerous for marginalised people in our community. Because we are
> communicating to them that we have certain standards, and then not taking
> any action to make sure that those standards are met.
>

Maybe I should have spent more words. Of course there are CoC items that
should and  can be enforced, but to me there
are also some with quite some elastic built in. For example we have a CoC
for email, do not use he/she and be polite. The first
part is easy to enforce, but the second part ? what you see as polite might
not be polite to me.


>
> A community is, in many ways, defined by whatever its leaders are prepared
> to tolerate. Our CoC is, and should continue to be, a document that
> outlines what we do not tolerate. And for that to mean anything, we need to
> put our money where our mouth is and enforce it.
>
I agree the CoC needs to contain what is not to be tolerated and will be
enforced. But may the rest is CoC good practice, which
to me is just as important for new people.


>
> And this shouldn't be optional for podlings or projects. This should apply
> across the board, for the whole org, like the foundation's bylaws
> themselves. Or again, it is useless.
>
> To make that work, we need to add three things:
>
> 1. A clear way for the document to be updated. We have a model on CouchDB
> (which is where the doc came from) and we can simply port that the
> Community PMC, where people can come to discuss changes.
>
+1

>
> 2. We need a foundation-level reporting mechanism (again, presumably
> coordinating this through the Community PMC)
>
I would not like the community PMC to become judges or police, ideally the
PMC should deal with it, and if they fail
we need an escalation mechanism.


>
> 3. We need clearly defined enforcement guidelines or punitive measures, so
> that people know what action will be taken, and when
>
+1

I hope that made my point a bit clearer, I do not think we disagree as such.

rgds
jan i.


>
> On Sat, 20 Dec 2014 at 21:14 jan i  wrote:
>
> > On 20 December 2014 at 20:55, Louis Suárez-Potts 
> wrote:
> >
> > > Hi,
> > > > On 20 Dec 2014, at 09:50, Jim Jagielski  wrote:
> > > >
> > > > This is great and, as noted, long overdue. Although the code
> > > > itself "simply" codifies what had been the tribal knowledge
> > > > of the ASF, and how we'd expected people to behave, NOT having
> > > > it written down was pretty sad.
> > > >
> > > > Thx to all for making it happen.
> > > >
> > > >> On Dec 20, 2014, at 6:33 AM, sebb  wrote:
> > > >>
> > > >> There are some useful links in the CoC blog:
> > > >>
> > > >>
> > > https://blogs.apache.org/foundation/entry/asf_
> > publishes_long_overdue_code
> > > >>
> > > >> For example,
> > > >> Ashe Dryden's introductory resource for learning more about how
> Codes
> > > >> of Conduct can help
> > > >>
> > > >> Perhaps these should be added to the ASF CoC page at
> > > >>
> > > >> http://www.apache.org/foundation/policies/conduct.html
> > > >
> > >
> > > So, now that it is written down—great—does this mean then that we will
> be
> > > asking all new projects (and podlings and everything else) to
> > obligatorily
> > > review it? As part of the Apache Way? That is, what is the relationship
> > > between this CoC and the Apache Way from the perspective of the new
> > member
> > > to Apache?
> > >
> >
> > maybe I see it wrong, but to me a "code of conduct" is more a guideline
> > than an actual rulebook. It is a description of how we would like to
> > interact with other, and therefore not something that should be used as
> > "you did not follow the code of conduct, so now I take action".
> >
> > I think it is important to see both the "apache way" and "code of
> conduct"
> > as guidelines, not something formulated by lawyers to stand up in court.
> >
> > So in essence we should all be aware of what the intention is and that
> > includes podlings coming to apache.
> >
> > rgds
> > jan i.
> >
> >
> > > Louis
> > >
> > >
> >
>

Re: Code of Conduct - links to why they are needed etc

[Noah Slater]

Jan,

Late to the party here, sorry. But I wanna reply to your point that the CoC
is not meant to be enforceable.

That is not the case, as I understand it. Indeed, an unenforceable or
not-regularly-enforced CoC is not worthless, it's actually *harmful* and
dangerous for marginalised people in our community. Because we are
communicating to them that we have certain standards, and then not taking
any action to make sure that those standards are met.

A community is, in many ways, defined by whatever its leaders are prepared
to tolerate. Our CoC is, and should continue to be, a document that
outlines what we do not tolerate. And for that to mean anything, we need to
put our money where our mouth is and enforce it.

And this shouldn't be optional for podlings or projects. This should apply
across the board, for the whole org, like the foundation's bylaws
themselves. Or again, it is useless.

To make that work, we need to add three things:

1. A clear way for the document to be updated. We have a model on CouchDB
(which is where the doc came from) and we can simply port that the
Community PMC, where people can come to discuss changes.

2. We need a foundation-level reporting mechanism (again, presumably
coordinating this through the Community PMC)

3. We need clearly defined enforcement guidelines or punitive measures, so
that people know what action will be taken, and when


On Sat, 20 Dec 2014 at 21:14 jan i  wrote:

> On 20 December 2014 at 20:55, Louis Suárez-Potts  wrote:
>
> > Hi,
> > > On 20 Dec 2014, at 09:50, Jim Jagielski  wrote:
> > >
> > > This is great and, as noted, long overdue. Although the code
> > > itself "simply" codifies what had been the tribal knowledge
> > > of the ASF, and how we'd expected people to behave, NOT having
> > > it written down was pretty sad.
> > >
> > > Thx to all for making it happen.
> > >
> > >> On Dec 20, 2014, at 6:33 AM, sebb  wrote:
> > >>
> > >> There are some useful links in the CoC blog:
> > >>
> > >>
> > https://blogs.apache.org/foundation/entry/asf_
> publishes_long_overdue_code
> > >>
> > >> For example,
> > >> Ashe Dryden's introductory resource for learning more about how Codes
> > >> of Conduct can help
> > >>
> > >> Perhaps these should be added to the ASF CoC page at
> > >>
> > >> http://www.apache.org/foundation/policies/conduct.html
> > >
> >
> > So, now that it is written down—great—does this mean then that we will be
> > asking all new projects (and podlings and everything else) to
> obligatorily
> > review it? As part of the Apache Way? That is, what is the relationship
> > between this CoC and the Apache Way from the perspective of the new
> member
> > to Apache?
> >
>
> maybe I see it wrong, but to me a "code of conduct" is more a guideline
> than an actual rulebook. It is a description of how we would like to
> interact with other, and therefore not something that should be used as
> "you did not follow the code of conduct, so now I take action".
>
> I think it is important to see both the "apache way" and "code of conduct"
> as guidelines, not something formulated by lawyers to stand up in court.
>
> So in essence we should all be aware of what the intention is and that
> includes podlings coming to apache.
>
> rgds
> jan i.
>
>
> > Louis
> >
> >
>

Re: Code of Conduct - links to why they are needed etc

[Louis Suárez-Potts]

Hi

this is a whimsical post. (also a top post)
But here’s a cute code of conduct video.

http://goo.gl/UZF7CW


> On 20 Dec 2014, at 15:14, jan i  wrote:
> 
> On 20 December 2014 at 20:55, Louis Suárez-Potts  wrote:
> 
>> Hi,
>>> On 20 Dec 2014, at 09:50, Jim Jagielski  wrote:
>>> 
>>> This is great and, as noted, long overdue. Although the code
>>> itself "simply" codifies what had been the tribal knowledge
>>> of the ASF, and how we'd expected people to behave, NOT having
>>> it written down was pretty sad.
>>> 
>>> Thx to all for making it happen.
>>> 
>>>> On Dec 20, 2014, at 6:33 AM, sebb  wrote:
>>>> 
>>>> There are some useful links in the CoC blog:
>>>> 
>>>> 
>> https://blogs.apache.org/foundation/entry/asf_publishes_long_overdue_code
>>>> 
>>>> For example,
>>>> Ashe Dryden's introductory resource for learning more about how Codes
>>>> of Conduct can help
>>>> 
>>>> Perhaps these should be added to the ASF CoC page at
>>>> 
>>>> http://www.apache.org/foundation/policies/conduct.html
>>> 
>> 
>> So, now that it is written down—great—does this mean then that we will be
>> asking all new projects (and podlings and everything else) to obligatorily
>> review it? As part of the Apache Way? That is, what is the relationship
>> between this CoC and the Apache Way from the perspective of the new member
>> to Apache?
>> 
> 
> maybe I see it wrong, but to me a "code of conduct" is more a guideline
> than an actual rulebook. It is a description of how we would like to
> interact with other, and therefore not something that should be used as
> "you did not follow the code of conduct, so now I take action".
> 
> I think it is important to see both the "apache way" and "code of conduct"
> as guidelines, not something formulated by lawyers to stand up in court.
> 
> So in essence we should all be aware of what the intention is and that
> includes podlings coming to apache.
> 
> rgds
> jan i.
> 
> 
>> Louis

Re: Code of Conduct - links to why they are needed etc

[jan i]

On 20 December 2014 at 20:55, Louis Suárez-Potts  wrote:

> Hi,
> > On 20 Dec 2014, at 09:50, Jim Jagielski  wrote:
> >
> > This is great and, as noted, long overdue. Although the code
> > itself "simply" codifies what had been the tribal knowledge
> > of the ASF, and how we'd expected people to behave, NOT having
> > it written down was pretty sad.
> >
> > Thx to all for making it happen.
> >
> >> On Dec 20, 2014, at 6:33 AM, sebb  wrote:
> >>
> >> There are some useful links in the CoC blog:
> >>
> >>
> https://blogs.apache.org/foundation/entry/asf_publishes_long_overdue_code
> >>
> >> For example,
> >> Ashe Dryden's introductory resource for learning more about how Codes
> >> of Conduct can help
> >>
> >> Perhaps these should be added to the ASF CoC page at
> >>
> >> http://www.apache.org/foundation/policies/conduct.html
> >
>
> So, now that it is written down—great—does this mean then that we will be
> asking all new projects (and podlings and everything else) to obligatorily
> review it? As part of the Apache Way? That is, what is the relationship
> between this CoC and the Apache Way from the perspective of the new member
> to Apache?
>

maybe I see it wrong, but to me a "code of conduct" is more a guideline
than an actual rulebook. It is a description of how we would like to
interact with other, and therefore not something that should be used as
"you did not follow the code of conduct, so now I take action".

I think it is important to see both the "apache way" and "code of conduct"
as guidelines, not something formulated by lawyers to stand up in court.

So in essence we should all be aware of what the intention is and that
includes podlings coming to apache.

rgds
jan i.


> Louis
>
>

Re: Code of Conduct - links to why they are needed etc

[Rich Bowen]

Patches are welcome but please consider the document RTC, with the R
happening on this list. Thanks.
On Dec 20, 2014 6:34 AM, "sebb"  wrote:

> There are some useful links in the CoC blog:
>
> https://blogs.apache.org/foundation/entry/asf_publishes_long_overdue_code
>
> For example,
> Ashe Dryden's introductory resource for learning more about how Codes
> of Conduct can help
>
> Perhaps these should be added to the ASF CoC page at
>
> http://www.apache.org/foundation/policies/conduct.html
>