Remember that new users don't have the same long-erm, big picture view of the projects.
other people on the internet have complained about the "pr method" of contributions for the same reasons, you don't get to know what people have been working on until they dump a huge change in a PR :)
s/new users/new contributors/
it turns out that this is a people problem
that is, we need to ask people to interact with us before they start coding, and we need to make sure that we interact with those people
alastairp: EXACTLY! Need to develop that into the process somehow.
we use jira as a task dump, not a project management software
and we work quite independently (that is to say, no "manager" making sure that people are working on what they say they're working on)
and we very often work on things that don't have tickets
he tells me to create a ticket if i report a thing :D
rdswift: you can disable issues on GitHub and e.g. point people to Jira. For picard documentation that would make sense. Either we should have it as separate project on JIRA, or we just add a Documentation component to the existing Picard project, which also would be fine IMHO
our jira has a "sign in with github" button too
You're doing good work, yvanzo!
+1 Thanks outsidecontext
For plugins I want to note that the GitHub issues where intentionally setup separate and we had been pointing users actively there. But that doesn't really work and not really solve the issues we have with plugin maintenance, so recently I have stopped redirecting user there when they open plugin tickets in JIRA
does the pull request merge button on LB still squash commits?
need to check the default but i enabled other options some time ago.
and PRs that are merged before a releaes is made goes into a "draft" release
so this is what we use to make our releases, and we make tweets and link to this page. I agree with reosarevok's comment about adding a "user-accessible summary", and this is a good place to use for monthly roundups