Fwd: [eclipse/microprofile] Operations (#21)

[Amelia Eiras]

Ondrej, you are just fantastic, thank YOU!

To all, 

From Ondrej’s 1st msg below seems that currently, I cannot add collaborate via PR to MP git if I am not a formal MP Committer for project?

Quoting you from first email —  in purple my replies: 

The Eclipse IP check failed for this PR. The following is required to pass the IP validations:

• sign the ECA or become the project committer at Eclipse   completed and processed by Eclipse Team on January 11th, 2017
• use git commit --signoff to sign off your commits and push them to GitHub   also done
• avoid using GitHub web interface to edit the repository - this never worked for me, either because it doesn't sign off the commits or because GitHub doesn't use the correct email address for commits   1 git account and 1 email connecting all OSS collaboration, clear. 

—

Thanks for clarification on how best to collaborate.  

As mentioned before, MP Project doesn’t need secretaries or mediators. Each active member ought to own & be enable to do stuff, add value at his/her proper speed, without delays. 

If assumption above is correct about the need of formal Committers, you can expect a list from me before next MP Hangout. 

 

My feedback on how slow we have been to add new Committers to MP is nothing, we are failing at it. 

We must do better!

Amelia Eiras 

https://twitter.com/ameliaeiras

http://www.tomitribe.com

https://www.tomitribe.io

Begin forwarded message:  second msg: 

From: Ondrej Mihályi <notifi...@github.com>

Subject: Re: [eclipse/microprofile] Operations (#21)

Date: July 27, 2017 at 12:44:08 AM PDT

To: eclipse/microprofile <microp...@noreply.github.com>

Cc: Amelia Eiras <aei...@tomitribe.com>, Mention <men...@noreply.github.com>

Reply-To: eclipse/microprofile <reply+00a3bed86ec4d8a1022d95d1fc68e051fd44a74...@reply.github.com>

There are a couple of other things that we documented in the Contributing Guidelines wiki page.

For this PR, only the following applies:

• for documentation, we decided to use adoc
• every committed file requires a license header (any type of file, even adoc - for an example, see README in microprofile-config)

None of the files in this repo has the license header - it's tedious but we'll have to add it for them too later.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Begin forwarded message:  first msg: 

Hi @aeiras, didn't you mean to create operations.adoc - a document with adoc markup?

The Eclipse IP check failed for this PR. The following is required to pass the IP validations:

• sign the ECA or become the project committer at Eclipse
• use git commit --signoff to sign off your commits and push them to GitHub
• avoid using GitHub web interface to edit the repository - this never worked for me, either because it doesn't sign off the commits or because GitHub doesn't use the correct email address for commits

—

[ondrej....@gmail.com]

Hi Amelia,

 

Signing the ECA is enough to send a PR. However, sometimes Eclipse validations fail for unknown reasons. In that case the best thing to do is resubmit with a new PR, maybe in a different way if possible. It took me a couple of PR’s myself to find the best way to create the PRs and setup my local git and IDE and I’m even a committer, so don't be afraid if IP validation fails sometimes.

 

To explain committers vs. collaborators:

 

Collaborators are people who just sign the ECA and that's it. They are allowed to send PRs, but not allowed to merge them. This is allowed only to committers who should review the PRs.

 

Committers are officially acknowledged by Eclipse as “owners” of the project. Each project has one or more lead committers, but this doesn't give them any special privileges. Committers are allowed to commit directly to any MP repository without PRs and can merge any PR. We have a habit that even committers raise PRs unless the change is trivial.

 

Committers don't own the GitHub repos and don't have all permissions to the repo, especially to modify the settings. Repos are owned by Eclipse and changes have to be requested at Eclipse issue tracker.

Reply to this email directly, view it on GitHub, or mute the thread.

—

 

[Amelia Eiras]

I love the MP working status of:  "We have a habit that even committers raise PRs unless the change is trivial.” 

 Self-awareness & time-window to receive FEEDBACK on PR, no matter code or just content,  submitted before adding stuff to Master is great. 

  

Can you tell me if MP tech team has yet decided on the expected max-time for when PR’s code are merged?  Compliance btw Eclipse, clearly… :) 

— I don’t write code, neither do many of the marketing team members, yet the mktg team, a section of Operations, will be expected to use git to also help set up their data on the 360 MP Skeleton for mktg.  

 

Documentation like you wrote below, where can we find it without spending hours researching?

Cheers and thanks OM! :)

Amelia Eiras 

https://twitter.com/ameliaeiras

http://www.tomitribe.com

https://www.tomitribe.io

[Ondro Mihályi]

Reply below:

Can you tell me if MP tech team has yet decided on the expected max-time for when PR’s code are merged?

There's no formal agreement about max time for open PRs. The current consensus is that PRs are usually merged without much delay, within one or two days. All depends on the character of the PR, some PRs don't require any discussion, just a review by another pair of eyes and can be immediately merged. On the contrary, there are some PRs that require a lot of discussion or are even only suggestions and may be closed if the team decides to not go with that direction.

I would separate PRs into these groups:

 - trivial changes with no need to discuss (grammar corrections, updates or additions to the documentation unless they have a big impact and need to be reviewed and discussed)

     - usually the first committer that reviews the PR automatically merges it

 - non-trivial technical changes

    - usually open for a couple of days, at most one week, then merged or closed based on the results of the discussion (no discussion is also OK and means the PR can be merged) 

 - non-trivial changes with big impact outside of the related component/repository

    - discussed in a new thread on the mailiing list, PR is left open until the discussion settles with an outcome and at least some agreement

 - PRs with suggestions of various approaches to a problem

   - this is to fuel the discussion and it is usually decided on hangouts where to merge them, close or postpone the idea

Specifically for the main microprofile repo and project documentation, most PRs should fall into the first 2 categories (trivial or non-trivial technical changes). That means that a PR, once it passes Eclipse IP checks, will be merged either immediately after one of the committers reviews it, or within a couple of days. If that doesn't happen, just comment on the PR - most committers (including me) will receive a notification about the comment to remind them to review it.

There's no documentation about this, because we've formed the consensus organically, but maybe now is the time to document it. The only related documentation is the Contributing guidelines page in the wiki.

--Ondro

There are a couple of other things that we documented in the Contributing Guidelines wiki page.

For this PR, only the following applies:

• for documentation, we decided to use adoc
• every committed file requires a license header (any type of file, even adoc - for an example, see README in microprofile-config)

None of the files in this repo has the license header - it's tedious but we'll have to add it for them too later.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—

 

[Amelia Eiras]

+ 1 on stating what is expected with complex or not PRs. 

Thank you for the detailed explanation, quite helpful!