[dspillett]

Moving the existing data over might not be a quick and easy task, so takes planning. Perhaps they intend to move over but didn't want to do everything in one go. Making many changes at the same time can be much more risky than a staged approach.

> are effectively gate keeping bug submission

Of course this could be a benefit… Have you seen the quality of bug reports coming from some people, even other devs? :-)

[lupusreal]

I've been on the front line of user bug reports for much of my career, so I definitely know what it's like. I also have very little sympathy for the complaints. Devs want to only take bug reports from other devs, and more so, only experienced devs, and more so, only devs specifically with experience with that specific project... That's great for the short term interests of the devs but not for the long term prospects of the project.

It's really not that hard to sort through user bug reports, find and categorize the ones that are actionable and respond with boilerplate requests for more information to the rest. It's not super enjoyable, it's work, but it's absolutely manageable and devs need to keep some perspective when they complain about it. I think maybe a mandatory part of every CS education should be an internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant.

[dspillett]

> Devs want to only take bug reports from other devs, and more so, only experienced devs, and more so, only devs specifically with experience with that specific project...

Nope, at least not this dev.

I want to take bug reports from people who can actually report something useful (not “something somewhere aint working” or “is the system OK?”), use their brain just slightly when making the report (if you got an error, it perhaps makes sense to include that message in the report, especially when you get a screen that explicitly states “please include this information in any bug reports”), and can read and pay attention to your responses when you request more information (actually answering the questions, all of them, not just one of them that they think is most relevant, or something different that they think is relevant instead) and who don't get offended when they respond to a further request for the required information with “this is getting urgent now!” and I reply with “then it is getting urgent that you send the information that I've requested twice now”¹.

> Devs want to only take bug reports from other devs

Furthermore, I've had terrible reports from devs and other technical types. Some non-technical end users have in the past sent me far better reports than some devs seem capable of. This is particularly galling because they then complain about how bad end user reports/requests are… I don't mind it from a fresh junior, but anyone else in our line of work should know better.

> It's really not that hard to sort through user bug reports…

It also isn't hard for people to properly describe the issue they are experiencing. It would be nice to be met half way. :)

TBH a lot of my irritation comes from the industry my employer operates in. While I try to stay away from the money and contracts side even more than I try to stay away from being end-user facing, I know that they often request our fees be itemised, and then expect a reduction for the bit marked “first line support” or similar because “our people will triage problems from our users and collate the details”, but their idea of “triage & collate” is just forwarding every email they get to [e-mail]… This narrow world view might not be relevant to a large public project.

> internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant

Younger me worked retail in a theme park, and did warehouse work, and had friends who managed a farm³, I have a fair idea what a hard day of work is.

----

[1] Actually, this no longer happens. My employer is bright enough that there is a buffer between me and client-facing tasks, except occasionally when something properly technical² needs discussing between their tech people and ours.

[2] Though “properly technical” can sometimes mean explaining how key-based auth works for SSH, to someone with a grandiose job title like “Infrastructure Architect”!

[3] Now that is a multi-faceted set of physical and mental complications which make my life, and those of people sending bad bug reports and change requests, look particularly easy.