Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Invitation: CiviCRM Release for May 2016 #1

Closed
totten opened this issue Apr 6, 2016 · 4 comments
Closed

Invitation: CiviCRM Release for May 2016 #1

totten opened this issue Apr 6, 2016 · 4 comments

Comments

@totten
Copy link
Member

totten commented Apr 6, 2016

Hello. My name is Tim Otten (@totten), and I’m going to be the release-manager for an upcoming iteration of CiviCRM (v4.7.6; scheduled for Wed, May 06, 2016). You’ve submitted a PR to CiviCRM’s master branch which is still open. Thanks for preparing that contribution and having some patience! I want to talk a bit about how we can get it merged for the upcoming release.

For the v4.7.6 release, we’d like to try something a bit different - and we’re looking for some help. There’s currently a backlog of ~70 open PRs[F1] ripe for review. I hope you’ll consider joining a working-group to review a small batch of them.

Most of these PR’s are borderline mergeable -- they pass the automated test-suite and sound plausible on the surface. But they deserve a little more careful peer review. How does the change look or feel when you actually use it? How good was the test-coverage over that function? What other use-cases might be affected?

I believe that -- if a handful of developers come together and coordinate in QA -- we can make a dent in the backlog. For example, if a couple developers have outstanding fixes for CiviContribute, they can check each others’ work and get both fixes released quicker (and with greater confidence).

If you’d like to participate, please take a look at this planning document:

https://docs.google.com/spreadsheets/d/14j8YgFTeMneuLI7iKOBhZYu1i1oksvKLG47W7hYUwU0/edit?usp=sharing

Skim the working groups to see if one of them appeals to your interests. If you can help with this month’s cycle, add your name and WG preferences under “Contributors”.

If you have comments or issues about process, please feel free to reach out through:

Thanks!

For reference, the following PRs are candidates for this release.
@civicrm civicrm locked and limited conversation to collaborators Apr 6, 2016
@totten
Copy link
Member Author

totten commented Apr 6, 2016

Just a clarification. The list above is flat, but the planning document (the Google Doc) breaks the items down into groups of 5-10 related PRs (ie proposed working-groups).

I think it's beneficial to form small working-groups of 2-3 people to collaborate on a batch of 5-10 PRs rather than have each person choose PRs a-la-carte. Some reasons/notes:

  1. This will be first time for a lot of folks doing code-review on civicrm-core, and there will undoubtedly be questions and judgment-calls in many PRs. If it were me, it would be easier to make those calls if I had a stable partner/buddy and could develop some good rapport/communication (e.g. showing up on IRC/Skype at the same times).
  2. I'm expecting we'll have some mix of skills/experience among contributors, and I want to make sure that strengths and weaknesses can be complementary. Administratively (for me as RM), checking that is much harder if we have to do it on PR-by-PR basis; it's easier to check for balance on a group-by-group basis.
  3. There's no obligation to accept/reject/review any single PR. Within a WG, you can set priorities however you want.

I'll try to update the listing above to better reflect WGs.

@civicrm civicrm unlocked this conversation Apr 6, 2016
@digitlimit
Copy link

Hi Totten,
Thanks for this honor. I will be happy to contribute to the upcoming release.
Please advice on further action to take since this its my first time.
Regards

On Wednesday, April 6, 2016 7:28 AM, Tim Otten <notifications@github.com> wrote:

Just a clarification. The list above is flat, but the planning document (the Google Doc) breaks the items down into groups of 5-10 related PRs (ie proposed working-groups).I think it's beneficial to form small working-groups of 2-3 people to collaborate on a batch of 5-10 PRs rather than have each person choose PRs a-la-carte. Some reasons/notes:

  • This will be first time for a lot of folks doing code-review on civicrm-core, and there will undoubtedly be questions and judgment-calls in many PRs. If it were me, it would be easier to make those calls if I had a stable partner/buddy and could develop some good rapport/communication (e.g. showing up on IRC/Skype at the same times).
  • I'm expecting we'll have some mix of skills/experience among contributors, and I want to make sure that strengths and weaknesses can be complementary. Administratively (for me as RM), checking that is much harder if we have to do it on PR-by-PR basis; it's easier to check for balance on a group-by-group basis.
  • There's no obligation to accept/reject/review any single PR. Within a WG, you can set priorities however you want.
    I'll try to update the listing above to better reflect WGs.—
    You are receiving this because you were mentioned.
    Reply to this email directly or view it on GitHub

@totten
Copy link
Member Author

totten commented Apr 8, 2016

@digitlimit , that's great. Please take a minute to look through the WG's and note which one appeals to you. If you're open, then say "Any". Put the choice in the spreadsheet (under "Contributors").

@eileenmcnaughton
Copy link
Contributor

I added a sheet in the s/sheet for our WG (Big Schemers) - maybe people will find that useful to look at as a template of sorts for thinkig about Qa

@totten totten closed this as completed Apr 16, 2016
@eileenmcnaughton eileenmcnaughton mentioned this issue Apr 19, 2016
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@eileenmcnaughton @totten @digitlimit