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.

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

CFEP-01 CFEP Purpose and Guidelines and CFEP-00 CFEP Template #1

Merged
merged 2 commits into from
Sep 23, 2016

Conversation

jjhelmus
Copy link
Contributor

Conda-Forge Enhancement Proposal for CFEPs themselves as well as a template for
future CFEPs.

Conda-Forge Enhancement Proposal for CFEPs themselves as well as a template for
future CFEPs.

All CFEPs will be resolved as either *Rejected*, *Accepted* or *Deferred*
depending on the consensus of the community. Once the community has reached a
consensus, the CFEP champion should update the Status of proposal and add a
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exactly mechanism on how a consensus is reached should be decided upon and included here.

@jjhelmus
Copy link
Contributor Author

Rendered versions of the README and CFEPs can be found in the jjhelmus/cfep01 branch


## Resolution

All CFEPs will be resolved as either *Rejected*, *Accepted* or *Deferred*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little nervous about the Deferred status. For instance, what limits how long something can be deferred? How do we ensure we actually reach a decision? Right now there are things that have effectively been deferred indefinitely. If we keep it, there need to be some limits on this so it actually gets accepted or rejected at some point. In some ways, I'd much rather see a proposal outright rejected if that is the case so that we can start making other plans.

Note that JEPs appear to exclude this status from the ones available too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like @mwcraig wording from above

Deferred CFEPs can be re-submitted in a new pull request if the circumstances that justified deferring instead of accepting or rejecting have changed.

@jakirkham
Copy link
Member

Thanks for putting this together @jjhelmus. This is very nicely done.

Basically my comments fit along one line, which is inspired based on what @pelson had said in our meeting discussing governance and CFEPs. Namely that it should be ok to merge things in Draft mode and often. Only after that do we start digging into a discussion about the proposal and come to some decision.

Other comments are directed at the decision process and making sure that it provides clear feedback and does happen.

@jakirkham
Copy link
Member

@conda-forge/core, please take a look at these documents that @jjhelmus has nicely put together for us and provide constructive feedback. These are laying the groundwork for how we make major decision on large changes going forward. So become familiar with it, ask questions about unclear portions, and make suggestions. We want to be sure we have firm footing going forward.

@@ -1,3 +1,22 @@
# Enhancement Proposals
conda-forge is a community led collection of recipes, build infrastructure
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

community ledcommunity-led

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@mwcraig
Copy link

mwcraig commented Sep 5, 2016

Thanks for putting this together @jjhelmus!

@jjhelmus
Copy link
Contributor Author

@jakirkham suggested:

This may seem like a small point, but actually I can see value in doing this as a second step. Namely we merge in Draft mode and then later someone (not even necessarily the original author) updates this to rejected. The value being twofold.

We are not relying on someone that just had their CFEP rejected to do this work. This seems minor, but I can certainly see people leaving abandoned PRs that were rejected.
We can offer up a summary judgement. Why did we reject it. What changes might allow for a future proposal to be accepted. Etc.

I've given some thought to a single step proposal process vs a two step process. Both have their merits and I'm really happy with either. The reason I prefer the single step process is that it allows an author to easily update the CFEP based upon feedback from the community and these is a single location where all discussion of the proposal takes place.

I think the mechanism for a two step process is more complicated. The proposal must first be reviewed only for formatting issues. I'm sure there would be many who would want to comment on the content which could result in the discussion being split into two locations. Once the draft is accepted the workflow seems a bit odd. Does the author open a new PR with no changed to the CFEP? Open an issue? If changes are requested how is this done?

I retained the single step workflow in the current draft but changed the text so that conda-forge maintainers change the status before merging the PR.

@jjhelmus
Copy link
Contributor Author

Thanks everyone for the feedback. I've tried to incorporate as many of the suggestions as possible into the new draft.

@jakirkham
Copy link
Member

Sure, so part of the reason I mentioned this is Jupyter tried doing it in one PR, but ultimately found it better to do subsequent PRs. See this discussion. In light of this GitHub addition, maybe it doesn't matter much.

I'm not picky either. Just trying to anticipate possible problems.

<table>
<tr><td> Title </td><td> A short title of the proposal </td>
<tr><td> Status </td><td> Draft | Proposed | Accepted | Rejected | Deferred | Implemented </td></tr>
<tr><td> Author(s) </td><td> Full Name &lt;[email protected]&gt;</td></tr>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A github handle would do it too.

@pelson
Copy link
Member

pelson commented Sep 22, 2016

So here is an interesting one - how do we go from proposed to accepted? Merge then new PR, or do it in the PR?

@pelson pelson merged commit 7994db7 into conda-forge:master Sep 23, 2016
scopatz pushed a commit that referenced this pull request Oct 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants