Mozilla Firefox – Official GitHub repo

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 support@ourdomain.tld… 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.

Once again, not so difficult to figure out even if you have no experience in the specific technical field of a Wikipedia article. So I have no idea what /u/casenmgreen's problem is.

Git certainly isn't anywhere close to the prettiest thing for ease-of-learning (and indeed used to be even worse), but Mercurial didn't seem particularly good either. Really for the common uses the difference is just needing to do a "git add ." before every commit, vs a "hg add ." before some.

All of my git usage has been on projects with ≤2 devs (including me; technically excluding a few largely-one-off OSS contributions of course), but I still use a good amount of local temp branches / stashes / rebasing to organize things quite often (but also have some projects where all I've ever done is "git add .; git commit -m whatever").

For one, it's semantic: It's only a contribution if it adds value to a project.

What you probably mean is that "not everything handed to us is a contribution". And that's valid: There will be a lot of issues, code, discussions, ideas, and what more that substract, or have negative value. One can call this "spam".

So, the problem to solve, is to avoid the "spam" and allow the contributions. Or, if you disagree with the semantics, avoid the "negative value contributions" and "allow the positive value contributions".

A part of that solution is technical: filters, bots, tools, CI/CD, etc. Many of which github doesn't offer, BTW. A big part is social and process: guidelines, expectations, codes-of-conduct, etc. I've worked in some Open Source projects where the barriers to entry where really high, with endorsements, red-tape, sign-offs, wavers, proof-of-conducts etc. And a large part is simply inevitable "resources". It takes resources to manage the incoming stuff, enforce the above, communicate it, forever, etc.

If someone isn't willing to commit these resources, or cannot, then, ultimately, the right choice to make is to simply not allow contributions - it can still be open source, just won't take input. Like e.g. sqlite.

I just signed out and started the signup flow. It allows me to use an email on my own domain, and I got as far as verifying my email before I canceled the flow, and there hadn't been any requirement for phone number of Microsoft account yet.