It’s quite hard to keep a positive image of someone in your head when the only times they interact with you are to parachute in on a bug tracker, tell you you’re wrong (without providing any constructive suggestions), and then parachute back out of the discussion again.
Don’t be that person.
That feeling when you spend some time working out a good implementation for a feature that someone wants to implement, tell them, and then they come back with something completely different and no mention of the original suggestion. 
…part 2 of 2: 
My analogy for #FOSS software project maintainership, especially in complex apps & languages, is:
You're the head mecha engineer for Alstom who built an automated maglev train for the city's free public transit.
Through months/years in operation, commuters report small issues or outages on the billboard. 2 of them are city maintenance techs who occasionally fix a wagon's door.
You wonder why other passengers don't train as techs.
Some top-notch FLOSS devs I cherish tell me of their fatigue, "Nobody asks a plumber to fix your issues for free!" and "Programming isn't innate, everyone can learn!"
With all respect, my head is bursting with so many ways that analogy isn't applicable, but it would never fit the 500 characters limit here; if one is interested to know why, this would need a 30 mins friendly discussion around drinks.
Meanwhile, here's my own analogy (1/2)…
That constant feeling of inadequacy as two new issues are filed in the time it takes you to fix one old one, and you know that nobody else is going to fix either of them.
Old, but good and chillingly accurate description of FOSS maintenance: https://nolanlawson.com/2017/03/05/
#MaintainerLife
Me: I’m going to have a really productive day triaging and reviewing merge requests today.
GitLab: Error 500
When we ask for a debug log in an issue template, it’s not to punish you. If you don’t provide the debug log, we almost always have to immediately ask for it, because it contains useful information (at the very least, the version of the software you’ve hit the bug on). This wastes your time and ours.
Decided to finally step off the "zero point something" versioning scheme treadmill for Amberol, and released 2024.1.
Fixed up a bunch of small issues that were tied up in my attempt at getting "1.0" out of the door, before realising that version numbers are complete fiction, and there's no reason whatsoever for an application to start out of "zero point" and reach the fabled "one point oh" status.
An epiphany for me about one of the reasons why working on FOSS software on your own (rather than in a dev partnership or larger team) is so demoralising: every single email/issue/merge request you receive is a distraction from what you’re actually trying to work on. Nobody else is advancing what you’re trying to focus on. Even if they are submitting perfect merge requests, those MRs are a distraction (they need reviewing, that takes time) and hence demoralising.
Support for async/sync/finish introspection annotations has landed in GLib for the next unstable release, https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3746
#GLib #MaintainerLife #gobject-introspection #GNOME
Nothing quite like asking 6 questions of someone in a merge request review and receiving an answer to just the first question.
What is the point of the time I put into this?
Designing your features so that all the thousands of lines of code and new UI have to land at once or not at all, is not a good plan. Any review/design comment on any part of it blocks all of it. People lose sight of the big picture and the small details. Nobody gets a boost from seeing progress landing.
Observation: often, the longer a large merge request has been sitting around, the more it makes people think that it’s stable and OK to merge (even if it’s not been reviewed)
The hard bit about code review isn’t writing the comment saying “we need unit tests for this”, it”s the thinking beforehand to work out how those tests could be written (mocking underlying system services or syscalls is hard), where they should be put, and what examples to link to so that the MR author has something to copy to make it easier for them to write the tests.
It turns out that I closed over 590 tickets in #GNOMECalendar in the past 1.5 years. That's 2x more than I thought!
Some quick facts on the remaining 282 currently opened tickets:
* 71 (25%) are "new feature" requests
* 70 (25%) are "enhancement" requests
* 101 (36%) are actual bugs, 50 of them are newcomers-friendly!
110 (40%) are newcomers-friendly tickets!
More insights in the upcoming #GUADEC presentation today.
My #OpenSource projects bug trackers email inbox has reached the maximum damage output limit that #FinalFantasy would allow. Where's my Level 4 Limit Break?
— Them: “Please test #GNOMECalendar's sidebar again”
— Me, coming back from another round of testing: “Code’s haunted”
— Them: “What?”
— Me, loading a pistol and getting back to the bug tracker: “Code’s haunted”
Today has been a day of assuming that contributors have tested the code they are submitting for review.
And finding out that they have not.
People ignoring issue reporting templates in FOSS projects has to be one of the most demotivating things. They file an issue, implicitly demanding my time and attention, but explicitly choose to not provide any of the information needed to fix that issue, despite being prompted for it.
I guess the kicker is that it demonstrates that action I take to try and make issue triage easier is explicitly dismissed. i.e. I can do nothing to make things better.
