-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Conversation
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 |
There was a problem hiding this comment.
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.
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* |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
@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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
community led
→ community-led
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Thanks for putting this together @jjhelmus! |
@jakirkham suggested:
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. |
Thanks everyone for the feedback. I've tried to incorporate as many of the suggestions as possible into the new draft. |
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 <[email protected]></td></tr> |
There was a problem hiding this comment.
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.
So here is an interesting one - how do we go from proposed to accepted? Merge then new PR, or do it in the PR? |
Conda-Forge Enhancement Proposal for CFEPs themselves as well as a template for
future CFEPs.