Re: Incubator policy wording

2019-07-31 Thread Felix Cheung
I think rewording the termination spew could help as there has been
feedback on incubator coming across as “unwelcoming” etc.

Just my 2c

On Wed, Jul 31, 2019 at 2:22 PM Justin Mclean 
wrote:

> Hi,
>
> Thanks for the feedback.
>
> > 1. Should we move disclaimer and release up instead of being the last?
> > Seems like good to be upfront with these
>
> For now I’ve just left thing in the order they were.
>
> > 2. About “It MAY consider the termination of a Podling if violations are
> > not corrected.“
>
> It practice this is probably not going to happen and there are going to be
> conversations with the podling to correct things way before we consider
> this. Each situation is going to be different so I don’t think we can put a
> general time frame on it. In general it needs to happen before graduation,
> and a s long as some progress is being made, all is fine. Also no timeline
> was specified before so adding one would change policy, which I think would
> need further discussion.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: Incubator policy wording

2019-07-31 Thread Justin Mclean
HI,

> A couple of suggested edits to the responsibilities.

Thanks for those.

> A note about "Podlings MUST NOT perform any releases”. I think that this does 
> not properly handle the reality of new Podlings like Zipkin that already have 
> existing communities and need to transition their release process to the ASF.

I agree, but the distinction is those are not Apache releases and the release 
management page covers that reasonably well. I was just trying to fix up the 
wording here, not change policy.

> We need to discuss how we provide the appropriate guidance for that aspect. 
> I’m not sure of the best way to describe this, but efforts should be made.

See [1]

Thanks,
Justin

1. 
https://incubator.apache.org/guides/releasemanagement.html#requesting_feedback_on_interim_non_asf_releases
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Incubator policy wording

2019-07-31 Thread Justin Mclean
Hi,

Thanks for the feedback.

> 1. Should we move disclaimer and release up instead of being the last?
> Seems like good to be upfront with these

For now I’ve just left thing in the order they were.

> 2. About “It MAY consider the termination of a Podling if violations are
> not corrected.“

It practice this is probably not going to happen and there are going to be 
conversations with the podling to correct things way before we consider this. 
Each situation is going to be different so I don’t think we can put a general 
time frame on it. In general it needs to happen before graduation, and a s long 
as some progress is being made, all is fine. Also no timeline was specified 
before so adding one would change policy, which I think would need further 
discussion.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: New Project

2019-07-31 Thread Ted Dunning
Oh... and the project sounds like a cool one!

(should have mentioned that before)


On Wed, Jul 31, 2019 at 12:06 PM Ade Sanni  wrote:

> Ok, sounds good.
>
> On Wed, Jul 31, 2019 at 12:02 PM Ted Dunning 
> wrote:
>
>>
>> Ade,
>>
>> Getting some code in place is a good first step. Getting a start on a
>> community is an important next step, and it is better done before coming to
>> Apache for a variety of reasons. One of the simplest reasons is that you
>> can't even make a release at Apache without having an active community.
>>
>> So first step is to build a group of people to work on the project.
>>
>>
>>
>>
>> On Wed, Jul 31, 2019 at 11:25 AM Ade Sanni 
>> wrote:
>>
>>> Hello,
>>>
>>> I would like to start a new project at Apache. The project is for a
>>> Java based screen recorder application. I already have some code.
>>>
>>> How do I get a proposal ready? I also need a Champion and interested
>>> developers.
>>>
>>> Thanks,
>>> A Sanni
>>>
>>


Re: New Project

2019-07-31 Thread Ade Sanni
Ok, sounds good.

On Wed, Jul 31, 2019 at 12:02 PM Ted Dunning  wrote:

>
> Ade,
>
> Getting some code in place is a good first step. Getting a start on a
> community is an important next step, and it is better done before coming to
> Apache for a variety of reasons. One of the simplest reasons is that you
> can't even make a release at Apache without having an active community.
>
> So first step is to build a group of people to work on the project.
>
>
>
>
> On Wed, Jul 31, 2019 at 11:25 AM Ade Sanni 
> wrote:
>
>> Hello,
>>
>> I would like to start a new project at Apache. The project is for a
>> Java based screen recorder application. I already have some code.
>>
>> How do I get a proposal ready? I also need a Champion and interested
>> developers.
>>
>> Thanks,
>> A Sanni
>>
>


Re: New Project

2019-07-31 Thread Ted Dunning
Ade,

Getting some code in place is a good first step. Getting a start on a
community is an important next step, and it is better done before coming to
Apache for a variety of reasons. One of the simplest reasons is that you
can't even make a release at Apache without having an active community.

So first step is to build a group of people to work on the project.




On Wed, Jul 31, 2019 at 11:25 AM Ade Sanni  wrote:

> Hello,
>
> I would like to start a new project at Apache. The project is for a
> Java based screen recorder application. I already have some code.
>
> How do I get a proposal ready? I also need a Champion and interested
> developers.
>
> Thanks,
> A Sanni
>


New Project

2019-07-31 Thread Ade Sanni
Hello,

I would like to start a new project at Apache. The project is for a
Java based screen recorder application. I already have some code.

How do I get a proposal ready? I also need a Champion and interested
developers.

Thanks,
A Sanni


Re: Incubator policy wording

2019-07-31 Thread Dave Fisher
Hi Justin,

A couple of suggested edits to the responsibilities:

- Welcoming new Podlings to become part of the Apache Software Foundation (ASF).
- Guiding Podlings to govern and grow their communities according to *the 
Apache Way*, the ASF's philosophy and guidelines for collaborative development. 
(Provide a link.)

A note about language:

"MAY choose to distribute” should be shortened to “MAY distribute"

A note about "Podlings MUST NOT perform any releases”. I think that this does 
not properly handle the reality of new Podlings like Zipkin that already have 
existing communities and need to transition their release process to the ASF. 
We need to discuss how we provide the appropriate guidance for that aspect. I’m 
not sure of the best way to describe this, but efforts should be made.

Thanks,
Dave


> On Jul 31, 2019, at 12:25 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> Anyone have any other feedback or shod I just commit the changes?
> 
> Thanks,
> Justin
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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



Re: Feedback requested: New committer invitation template

2019-07-31 Thread sebb
On Sun, 30 Dec 2018 at 18:24, Daniel Gruno  wrote:
>
> On 12/30/18 6:41 PM, Matt Sicker wrote:
> > I like this template suggestion. It may also be helpful to note that the
> > Apache ids must be letters and numbers only as some people request special
> > characters in their ids.
>
> Not to toot my own horn too much, but we also have
> https://asf.icla.online/ which simplifies the print-type-sign-scan-email
> routine for Apache ICLAs (and does verify that user ID is both available
> and matches our syntax). Could be an idea to point to that for easy ICLA
> work :)
>

Who is responsible for maintaining the site?
I could find no contact details, and no information on how to report
errors/request enhancements.

What happens to the generated ICLA?
This contains private information, but I could not find a privacy statement.

> >
> > On Sun, Dec 30, 2018 at 09:24, Craig Russell  wrote:
> >
> >> Hi Hugo,
> >>
> >> The intent is for the PMC member sending the invitation to do the check
> >> before sending the mail and edit the mail so the candidate only sees the
> >> appropriate option.
> >>
> >> I'll try to make this more clear in the instructions on the page that
> >> contains the sample email. [I originally had three different sample emails
> >> but they were all the same except for the paragraph B.]
> >>
> >> Thanks for the feedback.
> >>
> >> Craig
> >>
> >>> On Dec 29, 2018, at 9:32 PM, Hugo Louro  wrote:
> >>>
> >>> Hi Craig,
> >>>
> >>> +1 for the overall proposal. There is only one thing that I would like
> >> to clarify. Do you plan to have a custom email for each of the three cases
> >> (already have an Apache id, already filed an ICLA, and have not filed an
> >> ICLA), and research ahead of time to which case the person applies, or have
> >> an email that covers all the cases. If the later, my suggestion is that the
> >> email should clearly direct the recipient to choose specifically the case
> >> that applies to her/himself. I mean, have written something along the
> >> lines: If you already have an Apache is, follow these instructions, if
> >> already filed an ICLA follow these other instructions, otherwise follow
> >> this instead.
> >>>
> >>> Thanks,
> >>> Hugo
> >>>
>  On Dec 29, 2018, at 3:29 PM, Craig Russell 
> >> wrote:
> 
>  Hi,
> 
>  In order to simplify the process of granting new committers write
> >> access to a project's repository, I'd like to propose a change in the
> >> invitation letter sent to candidates after the PMC has voted to accept them
> >> as committers.
> 
>  The original is at
> >> https://community.apache.org/newcommitter.html#committer-invite-template
> 
>  It does not distinguish among these three cases: already have an Apache
> >> id, already filed an ICLA, and have not filed an ICLA. There are many cases
> >> where unnecessary work is done because of improper guidance.
> 
>  
>  To: joeblo...@foo.net
>  Cc: private@[PROJECT].apache.org
>  Subject: Invitation to become [PROJECT] committer: Joe Bloggs
> 
>  Hello [invitee name],
> 
>  The [Project] Project Management Committee] (PMC)
>  hereby offers you committer privileges to the project
>  [as well as membership in the PMC]. These privileges are
>  offered on the understanding that you'll use them
>  reasonably and with common sense. We like to work on trust
>  rather than unnecessary constraints.
> 
>  Being a committer enables you to more easily make
>  changes without needing to go through the patch
>  submission process. [Being a PMC member enables you
>  to guide the direction of the project.]
> 
>  Being a committer does not require you to
>  participate any more than you already do. It does
>  tend to make one even more committed.  You will
>  probably find that you spend more time here.
> 
>  Of course, you can decline and instead remain as a
>  contributor, participating as you do now.
> 
>  A. This personal invitation is a chance for you to
>  accept or decline in private.  Either way, please
>  let us know in reply to the [priv...@project.apache.org]
>  address only.
> 
>  [check http://people.apache.org/committer-index.html]
>  [B. If you accept, since you already have an Apache id,
>  the PMC will grant you write access to the repository.
>  ]
> 
>  [check http://people.apache.org/unlistedclas.html]
>  [B. If you accept, since you already have an iCLA on file,
>  the PMC will request an Apache id for you. In your response,
>  please choose an id that is not already in use. See
>  http://people.apache.org/committer-index.html
>  ]
> 
>  [B. If you accept, the next step is to register an iCLA:
> 1. Details of the iCLA and the forms are found
> through this link: http://www.apache.org/licenses/#clas
> 
> 

Re: Incubator policy wording

2019-07-31 Thread Felix Cheung
Hi Justin, two thoughts

1. Should we move disclaimer and release up instead of being the last?
Seems like good to be upfront with these

2. About “It MAY consider the termination of a Podling if violations are
not corrected.“
Should we put a timeframe on the correction? It seems like violations in
some cases do not prevent continuation of the incubation (eg so long as
they are corrected before graduation etc)

Thanks!

On Wed, Jul 31, 2019 at 12:25 AM Justin Mclean 
wrote:

> Hi,
>
> Anyone have any other feedback or shod I just commit the changes?
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: Incubator policy wording

2019-07-31 Thread Justin Mclean
Hi,

Anyone have any other feedback or shod I just commit the changes?

Thanks,
Justin

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