[Release Process] Feedback from Non-Maintainers

[RobDolinMS]

Much of the current release process draft focuses on maintainers, it may be worthwhile to add some specificity on how non-maintainers provide feedback.

/cc @philips

[wking]

On Fri, Jun 10, 2016 at 06:24:11AM -0700, Rob Dolin (MSFT) wrote:

Much of the current release process draft focuses on maintainers, it
may be worthwhile to add some specificity on how non-maintainers
provide feedback.

I was expecting to reply to the “we intend to cut $VERSION” thread on
dev@ and or ping specific maintainers on IRC. Is the concern that the
former would be too noisy and make keeping a count of the current vote
difficult? In the event that a pre-$VERSION thread picks up a lot of
traffic, you can always post periodic summaries of maintainer votes
and contentious issues to help casual readers stay oriented.

[RobDolinMS]

Thanks @wking.

IMHO, it would be good to include how non-maintainers can participate so that it's clear. For example:

• Non-maintainers can comment in the GitHub for the project and on the OCI Dev mailing list
• Non-maintainers can open issues and recommend which release they should be resolved in

Also, it would be good to include aspirational goal(s) of resolving issues raise by non-maintainers:

• Minor releases SHOULD address issues from all contributors targeted for that release
• Major releases SHOULD resolve issues from all contributors not explicitly assigned to a future release

[wking]

On Fri, Jun 10, 2016 at 08:33:08AM -0700, Rob Dolin (MSFT) wrote:

• Non-maintainers can comment

Yeah, it would be good to call this out in the release-plan
documentation.

• Non-maintainers can open issues and recommend which release they
  should be resolved in
  …
• Minor releases SHOULD address issues from all contributors
  targeted for that release
• Major releases SHOULD resolve issues from all contributors not
  explicitly assigned to a future release

While I like these ideas, they sound like general issues to me, and
are only loosely tied to the release-plan procedure. I'd suggest
documenting them in CONTRIBUTING.md.

[philips]

IMHO, it would be good to include how non-maintainers can participate so that it's clear. For example:

Non-maintainers can comment in the GitHub for the project and on the OCI Dev mailing list
Non-maintainers can open issues and recommend which release they should be resolved in

I think adding language like this to our contributing docs is a good idea. But, I agree with @wking that we need to trust the maintainers to listen to feedback and plan their releases accordingly.

Overall, I think adding your "Non-maintainers can..." language to CONTRIBUTING.md strikes the right balance.

[philips]

@RobDolinMS would you mind sending a PR to the template project for this?

[RobDolinMS]

I think this is reasonably covered by: "Voting SHOULD remain open for a week to collect feedback from the wider community " in https://github.com/philips/project-template/blob/56abe1227eaf11066fa0005d955b376cbd4883a5/GOVERNANCE.md