alastairp: Probably the year before last? That was the last year of GCI, where I specifically poked people to tag/label tickets. :x
alastairp
can someone help with adding bullet points about this discussion to the minutes
I'm falling behind
Mineo has quit
rdswift
reosarevok: That is a very important aspect. I have run into that before when I have developed a solution based on a Jira request, only to have it denied because it wasn't what the team had in mind.
Freso
reosarevok: I’m not fully sure what the current topic is 🙈
rdswift
Maybe all new requests should be reviewed / approved by the team and then have some development specifications added before marking them as "Available to be assigned".
CatQuest
Freso: me either :D
reosarevok
The current topic is kinda-sorta still "Making contribution easier for new contributors" but it developed also on "How to make sure users don't assume all tickets are open for work"
CatQuest
oh this.
reosarevok
Although it seems we're mostly still on "Making contribution easier for new contributors"
Freso
Okay. Using "Topic: Triaging tickets" for the stream for now.
CatQuest
it was the last ticket i linked to you. something related to instrument images
Remember that new users don't have the same long-erm, big picture view of the projects.
alastairp
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 :)
rdswift
s/new users/new contributors/
alastairp
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
rdswift
alastairp: EXACTLY! Need to develop that into the process somehow.
ruaok
guilty
alastairp
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
CatQuest
he tells me to create a ticket if i report a thing :D
outsidecontext
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
alastairp
our jira has a "sign in with github" button too
!m yvanzo
BrainzBot
You're doing good work, yvanzo!
rdswift
+1 Thanks outsidecontext
Freso
BUT!
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
alastairp
does the pull request merge button on LB still squash commits?
lucifer
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
rdswift
+1
alastairp
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