Refine project workflow#1534
Conversation
|
So, I know this is new territory, but am hoping that a discussions first workflow will help keep the "issues" and "pull requests" lists properly managed, and reduce the overall maintenance burden. It's the style I'm moving Django REST framework too, and likely other projects in Encode too. As it stands we're actually managing okay in HTTPX, but practically every OSS project eventually succumbs to an ever growing list of "Issues" being opened which may or may not actually be valid, well described, or confirmed as reproducible. By switching to discussions first, the focus shifts - a discussion no longer needs to be "closed", and isn't considered an issue unless the team raises it into one. We also want to help direct folks away from issuing pull requests without prior discussion. For example #1523 which is perfectly decently done, and is well intentioned, but may not be quite the API we actually want. This workflow change ought to help us discuss potential changes with contributors before they start work on the pull request itself. |
| @@ -0,0 +1,235 @@ | |||
| # Contributing | |||
There was a problem hiding this comment.
How is this file used? Thoughts on using a "see docs" stub like we had before? Helps reduce duplication of info and sources.
There was a problem hiding this comment.
Interface-wise, it gets linked to in this section...
(From the "New Issue" page)
I'm equally happy with it either as a copy of the docs, or as a simple docs link.
|
Will be a nice experiment. Happy to try discussions as the primary entry channel, especially as we've been waiting for them for so long! :) |
|
Right, let's give this a go, and see how we get on with it. |
2 participants
Following up on discussion #1493
.githubfolder.