Discussion-first workflows?

[tomchristie]

Hi folks,

So I'm thinking we might want to start encouraging users to default to "Discussions" as the first point of contact, rather than the "Issues".

The motivation here is that issues hard-require a maintainer to triage and eventually close them, and do a good job of leading to maintainer burn-out. With discussions, the modality is at least slightly different in that they're open-ended. Creating a discussion doesn't increment a highly visible counter that maintainers have to strive to keep down, and the wording of the name doesn't have the same loaded connotations of "something is wrong".

It seems to me, that for many cases it might be most appropriate for us to be promoting opening a "Discussion" above creating an "Issue".

We can start to do this by changing the config on our "new issues", which currently looks like this...

With the config defined here... https://github.com/encode/httpx/tree/master/.github/ISSUE_TEMPLATE

I'm thinking we might want to re-phrase the bottom one as "Chat".

I'd even consider dropping "Bug Report" and "Feature Request" completely, or else rephrasing things to strongly point towards "Discussions" as the starting point.

Any thoughts/feedback?

[florimondmanca]

I'd be happy with experimenting that, yes. :-)

Though I must say, given I also receive notifications for Discussions, I'm also tempted to try and answer questions on here as much as I'd do for issues, but I agree at least we don't get the visible counters and "must close this eventually" things.

Edit: ooh, custom notifications:

[euri10]

disclaimer: speaking for myself only, and for uvicorn only, if the discussion is not restricted to httpx of course :) and it's not a rant !

I would say that I like this proposition to :

start encouraging users to default to "Discussions" as the first point of contact, rather than the "Issues".

We currently point them to the chat and as I said it there, I'd shut it down entirely and keep only Discussions, mostly for the search aspect : same questions are answered over and over in chat mostly because people dont or cant search it. Now some people like to chat so shutting it down may be excessive !

As for this part, which I think is the most important:

The motivation here is that issues hard-require a maintainer to triage and eventually close them, and do a good job of leading to maintainer burn-out. With discussions, the modality is at least slightly different in that they're open-ended. Creating a discussion doesn't increment a highly visible counter that maintainers have to strive to keep down, and the wording of the name doesn't have the same loaded connotations of "something is wrong".

Speaking again just for uvicorn, the number of issues raised by people with the current organisation does not look like a problem for me, it's very manageable, I think most people do a good job at asking in the chat before so there's not such a thing as : there's too big a pile on my plate.

Now if I were following actively more repos I can easily see it being a problem, but I dont for the reason(s) below.

What I think is way more frustrating and prone not to burn-out but to bore-out is the sheer number of issues effectively solved and not reviewed or left abandoned.
I totally understand it's not everyone taste to look at other's people job, that you may not feel "concerned" by someone else issue, that some PR (mine included) are often not explicit enough, etc, etc
It's also not a reproach made to any maintainer here because I'm in the same boat: I don't review as many PR as I could, I try to do it on stuff that doesn't require a high level of "concentration" or doesn't require you to fully understand the library (some tooling PR, CI config, stuff like that).
But on more involved topics I mostly don't do it. There are starlette issues I could easily tackle but I decided not to knowing that if I do it chances for it to be reviewed will be fairly low, why bother ?

The irony with current organisation is that a PR has more chances to land if it comes from a total stranger.

If for every repo a clear goal / roadmap was discussed, it would be I think a first good step to bring more traction.
Have a PR template that sets requirements that would enable a reviewer to "jump" more easily in someone's work would be another good step, not sure it's feasible.
Ultimately I think that when someone is working on something, on his free time, with low chances for it to being even looked at, it is a recipe for him / her not coming back helping more in the future.

I thought it was worth mentioning in that discussion, despite I clearly don't have a ready-made solution in organisational terms to propose.

[florimondmanca]

Thanks for sharing your thoughts @euri10 :)

It occurs to me that a pull request template might be something worth considering, especially for newcomers. A structure I like to use is 3-parts: Description (what does this do), Motivation (why is this worth doing), Additional notes (extra context).

As for Uvicorn and Starlette, I also think we could be giving them some organizational love. Starlette's tracker is at > 110 issues and > 60 PRs. I noticed this before and it's kind of sad to see, but like @euri10 said, tackling it as an individual is a bit of a pain. 😄 We could plan or schedule an "agressive closure and cleanup" session and then start enforcing there the same kind of measures we put in place in HTTPX (which tbh is pretty manageable)?

[StephenBrown2]

I agree on the PR Template, especially with the possibility of empty-description PRs like #1486. I was hoping to point to such a template as guidance on correctly responding, but was surprised to not find one.

[euri10]

We could plan or schedule an "agressive closure and cleanup" session and then start enforcing there the same kind of measures we put in place in HTTPX (which tbh is pretty manageable)?

would be fancy doing it irl, as some of us are located in Paris, with loads of hydroalcoholic gel the cleanup should be pretty easy to handle industrially !

[tomchristie]

@euri10 Ah now, there's an interesting thought. A Paris-based encode sprint of some sort could work pretty well sometime once the restrictions have eased up a bit. I'm personally now avoiding flights wherever possible, but Paris is only a couple of train journeys away from me, and it's a hub that I bet a bunch of other folks might be able to make it too as well.