Clojurians Log v2

@alexmiller Apologies if this has been discussed before but it occurred to me that GitHub Actions could provide a nice experience for people who open Issues or Pull Requests on core repos by either 1. Automating the comment → close workflow that, afaict, you're doing manually or possibly even 2. Automating the comment → close + open an actual Jira ticket with the content of the Pull Request/Issue. What do you think?

probably true, although this is like <= 10 minutes of my time on an average week so not exactly a burning issue for me

I'm thinking of it less in terms of your own time (although of course I value that) and more in terms of how it presents itself to possible first time contributors (those most likely, I think, to be unaware of the contribution process).

The experience of "I tried to submit this issue/pr to <core repo> but was told in a somewhat timely fashion that it doesn't accept PRs and now need to do the work to convert it" vs. "I tried to submit… but the project automatically converted it to the proper format and told me where I could go to follow up" seems like it could be a step in the right direction.

I agree it's not a burning issue, of course, and it's possibly the kind of action that would lower the barrier to entry that I think the core team seems to prefer to be at least a little obtrusive. :)

the current contributing.md text should tell the submitter what to do at the time they try to submit

using http://ask.clojure.org is a low barrier imo

arguably lower than stackoverflow even

That's all probably true. I say this as a follower of most of these repos rather than someone's who's had beginners mind for a long time. No worries. It doesn't sound like it's worth anyone's time. Hope you're well. Thanks for all the work you put into this community. 🙂

no worries, thx for thinking about it

@timvisher I'd also note that Issues are turned off for (nearly) all of the core repositories so the only route into GitHub for those repos is via pull requests (which we cannot turn off, unfortunately). There may perhaps be an avenue via GitHub templates that might alleviate the temptation for folks to submit a PR where it could be made more obvious how to go about this (post on http://ask.clojure.org first, if something turns into a JIRA issue how to apply to become a contributor and how to submit a patch). But, yeah, as Alex says, this is such a small piece of work for maintainers to deal with overall that automation probably just isn't worthwhile.

I maintain four Contrib libs right now and I can't remember the last time anyone tried to submit a PR (instead of going through "normal" channels)...

we have pull request templates already (like https://github.com/clojure/tools.deps.alpha/blob/master/.github/PULL_REQUEST_TEMPLATE)

that's lagging current status a bit so this could probably stand to be updated and pushed into every project (some don't have this atm)

Ah, I probably just happened to pick a clojure repo that doesn't have that 🙂

Nope. It just doesn't show up until you actually click through to make the PR https://github.com/clojure/tools.deps.alpha/compare/master...add-lib2 -- does not show the template

(nor does just going to the repo and clicking New Pull Request)

You see the template when you on click Create Pull Request and get the form to write the description of it -- by which time you've already done all the work. Not sure if there's any way in GitHub to avoid that 😞

@seancorfield the work is still useful for jira though right? You just now need to generate a patch instead of opening a PR.

Assuming someone is then willing to go through the CA process and wait until they get approved and get a JIRA account and so on -- not withstanding the fact that before submitting a PR they should have already raised the issue on http://ask.clojure.org (or elsewhere) and gotten buy-in that it really is an issue and that a JIRA ticket would be created and that Clojure/core will accept a patch for the issue.

My point is that by the time that work should even get started a whole bunch of other "work" and discussion should already have taken place.

And anyone who actually has done that work would know that a PR will not be accepted.

So... anyone who goes straight to a PR against a library hasn't done any of that work, by definition, so they've gone straight to code, straight to submitting a pull request -- for a "problem" in their eyes that might not even be considered a problem by the maintainers. And since they've already "done the work" by the time they find their PR won't be accepted, they're probably going to be disappointed and may not even want to go through the proper process...

(which is all to say that it would be really nice to just be able to either turn the PR tab off on projects or at least ensure that even visiting the tab makes it clear that PRs are not accepted -- neither of which GitHub supports right now)