[DISCUSS] consolidating and documenting contributor guidelinees

[Sean Busbey <sb...@apple.com.INVALID>]

Hi folks!

Right now we have contributor guidelines in a couple of places:

* source tree as CONTRIBUTING.md and DEVNOTES, visible on GitHub
* confluence on a HOW TO CONTRIBUTE and Developer Section pages, linked from the website

We also have a few different ways of accepting contributions

* JIRA patches - review on JIRA or review in review board
* GitHub PRs

It looks like only the JIRA/reviewboard workflow is covered in our contribution guide, but the GitHub PR route has come to dominate.

I’d like to update our contribution guides to give new folks a clear single path to on ramp.

What do folks think about taking a GitHub centric approach?

Given our current community activity levels, IMHO minimizing friction from the audience of folks who have a GitHub account gives us the easiest path to casual contributions.

To start I’d suggest:

- remove review board use
- suggest all changes as PRs
- consolidate our project guidelines in CONTRIBUTING.md and DEVNOTES

—
busbey

Re: [DISCUSS] consolidating and documenting contributor guidelinees

[Bessenyei Balázs Donát <be...@apache.org>]

+1 on the things proposed


Donat

On Wed, Mar 9, 2022 at 2:18 AM Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
> > On Mar 8, 2022, at 12:39 PM, Sean Busbey <sb...@apple.com.INVALID> wrote:
> >
> >
> >> On Mar 8, 2022, at 11:44 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> >>
> >>
> >>
> >>> On Mar 8, 2022, at 8:55 AM, Sean Busbey <sb...@apple.com.INVALID> wrote:
> >>>
> >>> - suggest all changes as PRs
> >>
> >> Generally, I am OK with that. As there have been no commits and no other participants I didn’t see the point of doing PRs for all the work I have done so far for 1.10.0 as they would still be awaiting approval. In fact, I sent an email to the Flume private list in November informing them I was moving to CTR for this work due to the lack of activity in the project. I got approval for that from a couple of the active PMC members. However, I am happy to create PRs so you can review what I do before it gets committed from here.
> >>
> >
> > I see. I only meant as a way to get contributions as compared to Jira attachments. A move to CTR is significant though, I’ll make a note of it while consolidating the contribution guide. Should I describe the plan as we would stay CTR indefinitely? Or is this e.g. a short term way to get the 1.10 release out the door?
> >
> > I like self-merged PRs as a foothold for new contributors to get involved in reviews (as you noted). Over in Apache Yetus we use “Lazy Consensus” on PRs. Essentially, a PR is merged at the sooner of a +1 (from any contributor) or 3 days elapsing since posting. I don’t mean to presume it would help Flume, but it has worked really well for Yetus at balancing out when the small pool of regulars has overlapping contribution time.
>
> I would hope we would not stay with CTR indefinitely. But to have RTC you have to have people willing and able to perform reviews. I get very busy between my $dayjob and Log4j so I can’t always be as timely as one would like. I have no idea what Tristan’s availability is. Given your other ASF activities I don’t think getting your commit bit turned on here should be that hard. But once we have a number of people who can and do perform reviews it would be best to go back to RTC IMO. And yes, it would be impossible to get a 1.10.0 release using RTC.
>
> I would wait to discuss how to implement RTC until we get back to the point where it makes sense.
>
> Ralph
>
>

Re: [DISCUSS] consolidating and documenting contributor guidelinees

[Ralph Goers <ra...@dslextreme.com>]

> On Mar 8, 2022, at 12:39 PM, Sean Busbey <sb...@apple.com.INVALID> wrote:
> 
> 
>> On Mar 8, 2022, at 11:44 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> 
>> 
>> 
>>> On Mar 8, 2022, at 8:55 AM, Sean Busbey <sb...@apple.com.INVALID> wrote:
>>> 
>>> - suggest all changes as PRs
>> 
>> Generally, I am OK with that. As there have been no commits and no other participants I didn’t see the point of doing PRs for all the work I have done so far for 1.10.0 as they would still be awaiting approval. In fact, I sent an email to the Flume private list in November informing them I was moving to CTR for this work due to the lack of activity in the project. I got approval for that from a couple of the active PMC members. However, I am happy to create PRs so you can review what I do before it gets committed from here.
>> 
> 
> I see. I only meant as a way to get contributions as compared to Jira attachments. A move to CTR is significant though, I’ll make a note of it while consolidating the contribution guide. Should I describe the plan as we would stay CTR indefinitely? Or is this e.g. a short term way to get the 1.10 release out the door?
> 
> I like self-merged PRs as a foothold for new contributors to get involved in reviews (as you noted). Over in Apache Yetus we use “Lazy Consensus” on PRs. Essentially, a PR is merged at the sooner of a +1 (from any contributor) or 3 days elapsing since posting. I don’t mean to presume it would help Flume, but it has worked really well for Yetus at balancing out when the small pool of regulars has overlapping contribution time.

I would hope we would not stay with CTR indefinitely. But to have RTC you have to have people willing and able to perform reviews. I get very busy between my $dayjob and Log4j so I can’t always be as timely as one would like. I have no idea what Tristan’s availability is. Given your other ASF activities I don’t think getting your commit bit turned on here should be that hard. But once we have a number of people who can and do perform reviews it would be best to go back to RTC IMO. And yes, it would be impossible to get a 1.10.0 release using RTC.

I would wait to discuss how to implement RTC until we get back to the point where it makes sense.

Ralph

Re: [DISCUSS] consolidating and documenting contributor guidelinees

[Sean Busbey <sb...@apple.com.INVALID>]

> On Mar 8, 2022, at 11:44 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> 
> 
> 
>> On Mar 8, 2022, at 8:55 AM, Sean Busbey <sb...@apple.com.INVALID> wrote:
>> 
>> - suggest all changes as PRs
> 
> Generally, I am OK with that. As there have been no commits and no other participants I didn’t see the point of doing PRs for all the work I have done so far for 1.10.0 as they would still be awaiting approval. In fact, I sent an email to the Flume private list in November informing them I was moving to CTR for this work due to the lack of activity in the project. I got approval for that from a couple of the active PMC members. However, I am happy to create PRs so you can review what I do before it gets committed from here.
> 

I see. I only meant as a way to get contributions as compared to Jira attachments. A move to CTR is significant though, I’ll make a note of it while consolidating the contribution guide. Should I describe the plan as we would stay CTR indefinitely? Or is this e.g. a short term way to get the 1.10 release out the door?

I like self-merged PRs as a foothold for new contributors to get involved in reviews (as you noted). Over in Apache Yetus we use “Lazy Consensus” on PRs. Essentially, a PR is merged at the sooner of a +1 (from any contributor) or 3 days elapsing since posting. I don’t mean to presume it would help Flume, but it has worked really well for Yetus at balancing out when the small pool of regulars has overlapping contribution time.

Re: [DISCUSS] consolidating and documenting contributor guidelinees

[Ralph Goers <ra...@dslextreme.com>]

> On Mar 8, 2022, at 8:55 AM, Sean Busbey <sb...@apple.com.INVALID> wrote:
> 
> 
> Hi folks!
> 
> Right now we have contributor guidelines in a couple of places:
> 
> * source tree as CONTRIBUTING.md and DEVNOTES, visible on GitHub
> * confluence on a HOW TO CONTRIBUTE and Developer Section pages, linked from the website

I would suggest the CONTRIBUTING.md be updated and the confluence stuff go away.

> 
> We also have a few different ways of accepting contributions
> 
> * JIRA patches - review on JIRA or review in review board
> * GitHub PRs

I am not aware that review board is still used.

> 
> It looks like only the JIRA/reviewboard workflow is covered in our contribution guide, but the GitHub PR route has come to dominate.

Correct. I think review board was replaced by GitHub PRs. 

> 
> I’d like to update our contribution guides to give new folks a clear single path to on ramp.

I’m OK with that.


> 
> What do folks think about taking a GitHub centric approach?

+1

> 
> Given our current community activity levels, IMHO minimizing friction from the audience of folks who have a GitHub account gives us the easiest path to casual contributions.

+1

> 
> To start I’d suggest:
> 
> - remove review board use

As I said, I think that is just a documentation issue.

> - suggest all changes as PRs

Generally, I am OK with that. As there have been no commits and no other participants I didn’t see the point of doing PRs for all the work I have done so far for 1.10.0 as they would still be awaiting approval. In fact, I sent an email to the Flume private list in November informing them I was moving to CTR for this work due to the lack of activity in the project. I got approval for that from a couple of the active PMC members. However, I am happy to create PRs so you can review what I do before it gets committed from here.

> - consolidate our project guidelines in CONTRIBUTING.md and DEVNOTES

+1

Ralph