Convince github to create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary)

[isaacs]

Just what the title says.

I want to post issues for github.com on github.com, and discuss them with other github users, so that's why this repo exists. But it shouldn't exist. Github should take this over, and make it a thing.

This is valuable for all the same reasons why public issues forums on open source projects and other websites are valuable: it allows users to discuss and refine a use case that they're trying to get help with, allows us to help each other, and then when githubbers respond, it is clear that it's an issue that's being worked on and planned, so we don't feel ignored or neglected.

Of course, people often email support@github.com with issues about their credit cards, usernames, ssh keys, and other things that might contain private info. So it would take some care to help ensure that doesn't happen. Perhaps it would be worthwhile to add a feature to github issues that filters out likely private information, like anything matching /{[0-9]{4} ?){4}/ or whatnot could be replaced with XXXX XXXX XXXX XXXX.

[tekkub]

I just wanted to drop a quick reply so you'd know that we have noticed what you've created here. In the past we've dabbled with a number of different public forums and issue trackers, but for various reasons have migrated to providing only direct private support to users. We hope that anyone who stumbles upon this repo know that they can contact us directly with any issues or suggestions they have. We welcome any and all feedback.

That being said, I hope you understand that we may not keep a very close eye on this tracker as it is not an officially sanctioned place for GitHub feedback. You've put together a very nice README that communicates your intent and that you're not associated with GitHub in any way, but the repo name itself may breed confusion among users who never see that README. I'd like to suggest you rename the repo to something like suggestions-for-github to help clear up that ambiguity.

Love and octocats, --tek

[isaacs]

In the past we've dabbled with a number of different public forums and issue trackers, but for various reasons have migrated to providing only direct private support to users.

Sure. I've heard that before, numerous times, from you and other GitHubbers in our private email conversations.

And I think that is 100% the wrong decision for your users.

1. Since creating this repository, two of my issues have been addressed through creative ideas of other GitHub users. There is simply no way that could have happened without a public conversation. I would think that GitHub would care about this, not just "notice" it.
2. There's no way for me to keep track of the issues that I send to GitHub. That is, I actually forget that I've sent a feature request, bug report, or annoying UI glitch to you guys. That's really why I set up this repository, so that I can track my own requests. When I privately report an issue to GitHub, I don't get even so much as a tracking ID to refer to in subsequent conversations. The helpdesk at a typical airline, telecom, or insurance company does this better.
3. There is no visibility into the opinions of other GitHub users of a suggestion. If I suggest something that most users would be super annoyed by, well, you might know that, but I probably never will. Since starting this repository, I've gotten a lot of feedback from other GitHub users about my own suggestions, which I never would have known otherwise. In at least one case, another GitHub user strongly disagreed with my point of view, and it was a very enlightening conversation.
4. There is zero visibility into the opinions of GitHub about my suggestions, even! When I suggested (via email) that GitHub needs to use a public issue tracker in the way that your users use public issue trackers, I was told that GitHubbers "use the shit out of" Issues. However, the whole point of a public issue tracker is that it adds visibility into the software maintenance process. Feedback is public, and users interact with one another. GitHub doesn't do this with github.com, so no matter how much shit is used out of Issues, it's not being used on your actual product in the ways that your product's users are using your product on their products.

The fact that you can only say "various reasons" for not providing a public support forum is part of the problem. GitHub is a crucial part of the open source software community, but is run in an even more closed-door fashion than Microsoft or Oracle. Suggestions are taken under advisement, processed through an internal cadre of product managers and user experience experts, and software developers, and then handed down to the users in releases that bear no direct connection to the initial request.

we may not keep a very close eye on this tracker as it is not an officially sanctioned place for GitHub feedback.

I don't expect anyone at GitHub to keep a close eye on this tracker. But, if you're smart, and care, you will see that it's a good idea to pay attention to the ways in which your frustrated users go out of their way to make their feedback as useful as possible.

I have not seen any compelling reasons for not having a public issue tracker for GitHub. I haven't even seen any evidence that GitHub actually accepts that there would be any value to this, or any interest in addressing the potential pitfalls! Do you have any new information about why public issue tracking is so verboten for GitHub, other than the reasons cited in this issue?

[tjfontaine]

I can see GitHub feeling concerned about sensitive information being leaked in a public issue tracker, as it happens public repositories care about that #37

Maybe GitHub is also concerned about the flood from trolls as people pile on complaining about their issue not getting the love they want, public repositories also care about that #38

[chadwhitacre]

Sent the following to support@github.com:

Greetings,

First, please allow me to apologize. I pulled a stunt today where I created a "github.com" repo and added all members of the GitHub organization on GitHub as collaborators. It was wrong of me to spam you all, and I apologize.

The context for my mistake was a conversation I was having with @holman and others on Twitter, and I was hoping we could pick up that conversation here on support@github.com. I'm given to understand that this email channel is Very Important to the way GitHub functions, and is backed by a finely-tuned internal application (maybe this?).

What I'm struggling with is the mismatch between how support works for open-source projects and how support works for GitHub itself. I don't like emailing support@ with issues because it's not public. I can't point other people to the conversation, I can't find out who else shares my problems, and I can't find out how others work around them. It's just not social.

Tweeting @GitHubHelp is public and social but it isn't a good tool for anything more than the simplest issues.

I learned today of another unofficial GitHub repo, isaacs/github, that is a month older than mine and has 50+ issues in it. I've nipped mine in the bud and started filing issues there instead.

One thought that occurs to me is that maybe an email bridge could be written that proxies messages back and forth between isaacs/github and support@github.com. A hack, and after my misfire this afternoon I'd better not move forward on it without your approval.

What's the state of the internal conversation around this issue? What can I do to help?

chad

---

Chad Whitacre, Founder, Gittip https://www.gittip.com/ https://twitter.com/whit537 chad@zetaweb.com +1-412-925-4220 (cell)

[chadwhitacre]

I just went back and actually read this thread. Um, +1. :dancer:

[chadwhitacre]

Response from @nuclearsandwich:

Hi Chad,

The reason we handle issues on a one-on-one basis is because unlike an open source project, the individuals reporting bugs to GitHub.com can't check the source. So if two people report the same symptoms, it's not always a sure bet the issues are related. Where workarounds are suggested by staff, they are likely temporary measures tailored to a specific situation and the last thing we want is a permanent thread online where a GitHubber tells someone they need to pet the monkey while walking the dog or their cake won't bake because of a bug with the oven. Only to fix that bug and have everyone complain for the next three years because they thought they had to pet the monkey while walking the dog in order to get cake because that's what it said to do in the one thread they found.

The issue comes down to something I refer to as canonical sources of truth. Right now GitHub.com has three, GitHub.com itself, help.github.com, and GitHub Support. These three things are always kept up to date with the latest information about GitHub.com. Before we ship new changes, we have to make sure our sources of truth will be updated with them. Updating GitHub.com is straightforward enough since you can ship your feature or fix as well other changes necessitated by it all at once. Updating the help articles involves contributing new documentation or making sure that screenshots have current visuals for GitHub and keeping support up to date usually happens via Campfire chat or an internal issue.

Adding any kind of official community Issues repository would add a fourth source of truth and one that is far more difficult for us to maintain effectively. Heroku ran into the same issue some time ago and they made the decision to retire their mailing list, after some push back, they instead decided to hand it off to the community so that no Heroku employees are dedicated to moderating the list. They had very similar reasons for doing so that we have for keeping issues routed through our tools: It was too difficult to manage the mailing list as a canonical source of truth and moving from a conversation in a public mailing list to a private thread in a support tool was creating lots of repeat questions and frustrating experiences for Heroku's users and staff alike.

If you want to talk about issues or problems you have with GitHub with other GitHub users, you don't need our permission to do so. Talk about stuff and have ideas, maybe even make some of them a reality using the GitHub API. We can't be active in every user forum, even though we may stop by from time to time and lurk. So when that community discussion becomes so exciting that you want to share it with us, it's time to drop us a line at support@github.com

With regard to your proposed email bridge, please don't do that. You have complete freedom to do whatever with the replies you get from GitHub, though automating that might come back to haunt you the next time you forget your password after a few drinks, but creating a public bridge would give people the impression that whatever issue list you're using for this proxy was an official way to contact GitHub which would not be the case at all.

This, along with the reasons explained by Zach and Tekkub which you've seen previously, is why we handle Support at GitHub the way we do.

Cheers, Steven!

[chadwhitacre]

Thanks for the response. Do I have your permission to share this publicly?

Chad,

If you would like, you're welcome to do so. Thanks for asking. I would ask you to remember that this is a conversation between yourself and GitHub and that choosing to share our replies doesn't mean this will become a conversation we continue to have in public. It is more like a source code drop than an open source conversation.

Cheers, Steven!

[isaacs]

@nuclearsandwich I'm all too familiar with this problem! You realize that open source projects face this as well, right? That's precisely why we've asked for the ability to close issue threads.

I asked for this via support@ and have repeatedly discussed with GitHubbers on Twitter and tried to explain why this is extremely problematic for npm and Node in particular. People see an error code, google for an issue, and comment on something that was posted before literally every single line of the program was rewritten, adding their info to the pile. Users don't check the source before reporting an issue, basically ever. It causes exactly the problem you're describing.

Allow me to list the reasons I've heard for GitHub not using a public support forum:

1. Users sometimes post private data to public forums, and there'd be no way to correct that. #37
2. People pile onto different issues with surface similarities, and it's difficult to direct them elsewhere. #38
3. GitHub doesn't want to make promises about what fixes will be made to the product. (I don't have an issue for that, because I don't think that's a justifiable problem; it's just laziness and poor customer support.)
4. GitHub's internal tracker has more features. (Can't really evaluate this one. I assume it MUST be better than Issues, since people use it who can actually fix it, and Issues is riddled with problems.)

These are all just reasons to not use Issues in the first place, which apply equally to your users problems! This is why I publicly chastised GitHub in the past of not dogfooding Issues, only to be told that GitHub "uses the shit out of Issues", because some GitHubbers contribute to open source projects.

However, organizationally, you don't actually expose yourself to the problems that your users are facing every day with your product, because you're not using your product the way that your users are. This is what we call the Quality Death Spiral. You're not using your inadequate product, because it is inadequate, and so you never notice or fix its inadequacies.

Frankly, the excuses I've seen for not having a public support forum of any sort, all boil down to "GitHub doesn't care about open source maintainers". You face the same problems we face, but rather than fix them, you're deciding to just not use your product. Some of your most active users are going out of their way to provide SOME kind of feedback in a public way, because we all actually know that, even despite all the problems with GitHub Issues, doing it in public is the right thing to do, and we're repeatedly told by GitHub employees that we're a nuisance, and wasting our time.

The sad thing about this is that no one at GitHub seems to see that any of this is a problem.

I'd be much happier with GitHub if you could just come right out and say that your paying customers are not your priority, and you're only interested in big enterprise sales. At least that would be believable.

[chadwhitacre]

@isaacs Whoa! That kind of frustration is unlikely to actually move the ball down the field, imo. Let's give GitHub the benefit of the doubt: They're supporting 3+ million users with only ~180 people. They've got all kinds of scale issues that I for one don't have the experience to imagine. Scaling that quickly while maintaining quality is surely a challenge, and imposing constraints in order to keep things manageable is surely understandable.

That said, GitHub does walk a fine line between propriety and open-source, and I think this issue gets to the heart of the matter. It's an even bigger challenge to figure out how to do open customer support for 3+ million people. No-one has figured that out yet, though if anyone is up to the challenge, surely it's GitHub. I think that's the framing that's going to move us forward here, albeit more slowly than we might like.

I think our best bet is to keep trying to raise this issue for public debate, engage those GitHubbers that resonate with this concern, and figure out a way forward together. The alternatives I can imagine—passive-aggressively cross-posting to support@github.com anyway, or bailing in favor of GitLab—are rather less satisfying.

[chadwhitacre]

Hey @adamstac @pengwynn, wanna do a @TheChangelog show re: https://github.com/isaacs/github/issues/6? :-)

https://twitter.com/whit537/status/353321249969160192

[chadwhitacre]

No go on @TheChangelog.

[adamstac]

I mentioned on Twitter that our M.O. is to cover the positive impacts to software development and open source and the people making them happen.

However, a conversation with @pengwynn and team on support at GitHub. That's different.

On Friday, July 5, 2013, Chad Whitacre wrote:

No go on @TheChangelog https://github.com/TheChangelog.

— Reply to this email directly or view it on GitHubhttps://github.com/isaacs/github/issues/6#issuecomment-20547032 .

Sent from Mobile

[chadwhitacre]

@adamstac Right, thanks for weighing in. :-)

Honestly, I think GitHub is too far along to alter course here. I plan to continue using this repo to track my own issues with GitHub together with others, but I don't really expect to budge GitHub's commitment to closed support and I'm not interested in adopting the role of an activist on this issue. Instead, I hope to explore "open support" and how to scale it to millions of users over on Gittip.

[adamstac]

I feel you, and that's why I don't think the topic is a fit on The Changelog. Thanks for thinking of us though!

On Friday, July 5, 2013, Chad Whitacre wrote:

@adamstac https://github.com/adamstac Right, thanks for weighing in. :-)

Honestly, I think GitHub is too far along to alter course here. I plan to continue using this repo to track my own issues with GitHub together with others, but I don't really expect to budge GitHub's commitment to closed support and I'm not interested in adopting the role of an activist on this issue. Instead, I hope to explore "open support" and how to scale it to millions of users over on Gittip https://www.gittip.com/.

— Reply to this email directly or view it on GitHubhttps://github.com/isaacs/github/issues/6#issuecomment-20547388 .

Sent from Mobile

[tjfontaine]

I think it would be prudent for GitHub to have a summit with @isaacs and other leads from projects with popular repositories on GitHub. The point is for projects truly "using the shit out of issues" it feels like the "issues with issues" conversation just enters a black hole.

Meanwhile outwardly their development focus has been more on iterating over the UI and developing their social network, while continuing to ignore the existing workflow problems that really are a point of frustration for projects.

I do appreciate they've been paying down technical debt on the disastrous backend design decisions they made initially--everyone is happy that the file server(s) aren't falling over consistently.

[Utumno]

Actually I spent around half an hour googling for the github tracker - only to go through this and realize there is no such a thing as a github tracker. A shame - there should at least be a feature request tracker for the reasons outlined in this thread.
+1 for your initiative

[patcon]

:+1:

Seems like the wicked problem of solving integration of public issue tracking and private employee conversations is worth solving.

GitHub has a badass, full-featured API, so I figure some sort of solution must be possible. Maybe a bridge between a public and private issue queue, in which comments are synced, but a certain keyword (#private?) in the private issue tracker results in that comment not syncing?

But then again, I don't understand GitHub's internal processes, so I can imagine this wouldn't be robust enough :(

[chevcast]

I'm glad the staff has chimed in here but searching for "github issue tracker" is a nightmare because everyone uses github as their issue tracker for their repos!

I searched forever to get here only to be disappointed :(

It really is a shame that this is not a thing.

[rlidwka]

This message was displayed when I moved to https://github.com/contact from here.

Now I'm considering what's happening here, and thinking that this message must be right. Laughing out loud.

ps: +1 to this issue of course

[juniorplenty]

Just adding this as an example, for features at least:

http://help.hipchat.com/forums/138883-suggestions-ideas

[foxbunny]

FWIW, BitBucket has had a public bug tracker for as long as I can remember, and they actually discuss and solve issues there. Not always in a very friendly way, but still, it's better than a private one-on-one.

[reedstrm]

An example of another public-participatory web company: trello.com They dogfood their boards for the trello.com and the mobile apps as well: https://trello.com/b/nC8QJJoZ/trello-development

This is admittedly a 'read only' interface to their dev process: feature requests and bug submissions still go through email or bug submission forms, so there's a triage step. Perhaps that's what Issues needs: a way to make the public view of the issues on a repo only 'accepted' or 'confirmed' issues, while members of the repo can confirm/reject other, submitted issues. Github.com could experiment then with pushing vetted results from emails out to such a repo/Issues instance.

Their at 5 million users, BTW.

[stuartpb]

I'm just CCing all my (non-personal) support@ issues to this repo, and telling folks like @jdalton about this when they mention issues they have with GitHub (jdalton mentioned an issue where Github isn't reflecting garbage-collected repository sizes).

Hopefully we can make using this repo to discuss public issues with GitHub common enough that it eventually changes @tekkub's mind and gets adopted by GitHub proper as a matter of course.

[AnneTheAgile]

+1 I naively assumed since Github is 'the' way to have great feedback and openness that they would belove their dogfood. Rats. Ty for a place to track questions and issues.

[stuartpb]

What's most ironic is, from emails I've received regarding issues I've reported, it would appear that GitHub is actually using JIRA (at github.atlassian.net) to track issues on at least some projects (specifically github/linguist#917).

[AnneTheAgile]

Public Jira would also be quite acceptable! Other projects use that.

[jantman]

The irony of this really is terribly painful...

[rektide]

Once I mentioned in #github that they should attach anchorables to markdown headers and rick filed a public issue in github on github & it got fixed. I felt bad for not getting any credit. Today everyone feels bad for all contact harboring hope for/with github.

Also if you do try and contact them, #326 happens and it really makes you feel powerless: your contact disappears, and rather than get a start of dialog you get a "thanks! our robots will take this and do something with it" message about how your convenyance is going to make it through postal. Have fun waiting till then.

[flaupretre]

Next github automatic message :

"Thanks for your suggestion ! we will silently ignore it because we are smarter. If your suggestion was relevant, it would be already implemented. Don't be frustrated, we could have stolen your idea without anyone ever knowing it was coming from you. Feel free to send other suggestions, they will follow the same way."

The most ironic point here is that github's argument tend to demonstrate that IT projects in general should not use collaborative tools ! Some may even be understood as arguments against collaborative open-source development !

A special mention for the concept of 'canonical sources of truth'. Last time it was used, it was 20 years ago, a few days before the last IT company providing support through one-way opaque email only went bankrupt :) Even Oracle wouldn't dare it today. Hey, Steven, if you really believe the bullshit you're feeding us with, don't ask me to work with you :)

Congratulations, GitHub, you're ready now. The next step is to call Microsoft and propose a merge.

I know none of you will ever read this message, and you don't care about the opinion of anybody on this page, but the IT developer's world is volatile, quite binary in its appreciations, communication is essential there, bad buzz has terrible effects and, technically, you have reasons to be proud of the services you provide but it is far from the ultimate, perfect, solution we dream of.

When a company like yours becomes big enough, it often forgets that its relationship with its user base is just a question of trust. If they have reasons (real or not) to doubt, are frustrated, and an attractive alternative solution is mature, you're dead. That's the sad rule : no gratitude for years of free service. Worse : the more someone loves and trusts you today, the more he may prove ungrateful and even hate you tomorrow. And paying entreprise users are not the solution as, if open-source projects massively migrate to another site, you will be amazed to see how quickly they follow. The relationship is different but it's a question of trust too, not the same trust but the effects are the same. Someone is always flying under you. You know that, you did it to sourceforge, who will do it to you ?

3 million users today, how many yesterday ? how many tomorrow ?

My primary objective, when I found this page, was to ask github if they could allow creating a pull request from a branch, before anything is commited. This way, people can start commenting a RFC, for instance, even if you didn't push any change yet. I also wanted to propose my help to design and implement an RFC tool, a long-awaited feature. But, from what I read here, it is clear now that I am not skilled enough to work with such smart people. Not a problem, I'll spend more time working with people who value the help I can offer...

[stuartpb]

My primary objective, when I found this page, was to ask github if they could allow creating a pull request from a branch, before anything is commited. This way, people can start commenting a RFC, for instance, even if you didn't push any change yet.

You used to be able to start a pull request as an issue, and then later use hub pull-request -i to convert it to a pull request. Apparently, GitHub has dropped this feature, in favor of creating an issue and then creating a PR that references the number of the issue it's meant to address (see also https://github.com/isaacs/github/issues/93#issuecomment-23979266).

IMO, this is a totally reasonable model (where pull requests always refer to code and issues always don't): this way, the discussion of the issue doesn't have to be tied to the way any one PR tries to solve it, and another PR can come along and reference the same issue to put forth an alternative solution.

[stuartpb]

Just adding a note on this issue, since this seems to be the main thread for all meta-discussion around this repo:

I've written https://ghes.github.io/isaacs-github-contact-xposter/xposter.user.js as an extension (to address #94 and #326) that makes it easier to copy any support emails you send to GitHub as an issue on this repo.

[garagatyi]

+1 to create issue tracking for github. At least for feature requests.

[ismay]

Completely agree. Weird what Github's doing here, doesn't fit with their open and progressive stance on other subjects.

[cirosantilli]

+1

Another possible rationale: to keep information away from competition.

If the issue tracker is public, competitors of similar products can know what people want and implement it first.

Also, even if GitHub implements first, and then a competitor follows, the competitor could argue that the idea was public knowledge before that.

Finally, you look smarter if people don't see your bugs :-)

[runsense]

hi, just a little bug!! when i post a file with a lowercase name, or upper..., and i change after a name, a changement is never see. Maybe just on gh-pages!!

[hunterboerner]

@runsense that is not a GitHub bug, your filesystem is case preserving. This stackoverflow question explains it well: http://apple.stackexchange.com/a/22304

[fyngyrz]

I've written a macro language that integrates content with content management. The initial target (for me) was HTML source, but it's more than powerful enough to handle just about any type of source.

The language uses [ ] and { } to manage contexts; keywords in the language immediately follow the opening [ and { characters. It's very simple in terms of syntax.

I'd very much like to be able to syntax color this stuff in my documentation here on github, but all I can find in github's syntax support is a depressing remark something along the lines of "we'll consider adding syntax support once hundreds of users are using your language."

It would be a huge boon if, strictly within the context of the language's repo, at least a minimal syntax coloring could be set up.

I suggest that when a syntax coloring definition reference in a code fence matches a corresponding syntax definition in the same repo, that it be used. This means that 1: the development of the symtax definition is on the shoulders of the repo owner, and 2: that any weirdness with the definition affects no one but the repo owner.

Given the way that github's syntax coloring works, I suspect this would be extremely easy to implement. I hope it will be considered.

I've sent this to the support link above as well, but am very interested in any feedback here.

[AshutoshPradhan]

I modified the code base and commit the code to git but when I am trying to build, I am getting following error. Can Anybody help ASAP. To https://git.heroku.com/xxx.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'https://git.heroku.com/xx.git'

Thanks in Advance

[kenorb]

@AshutoshPradhan How this is related to this issue? Use Google. See this.

[sarod]

:+1:

[barcher]

It would be nice to switch the branch a PR is compared against after it is made. This gets annoying since it requires opening a new PR currently.

[karenetheridge]

@barcher I'm not sure what you mean by "it", because you can force-push to a branch to change the contents of a PR. Just don't use the master branch for your PRs, or you'll not be able to do any other development on that repository while your PR is open.

[barcher]

@karenetheridge when a PR is opened for a feature, say feature/foobar and compared to a target branch, say development, there is no way (that I know of) to change the target branch to master, for example from the UI. of course, you could close & open a new PR with the correct target branch, but this is cumbersome, annoying, and counterproductive to meaningful discussion that has already been contributed.

[karenetheridge]

@barcher ah I see, I didn't catch that you were talking about the target branch, rather than the branch that contains the changes.

[barcher]

@karenetheridge gotcha. yeah, it's more of a pain for the purpose of collaboration rather than version control. especially if your PR has N comments.

[jitbit]

+1 to make an issue tracker for Github.

Github's closest rival - Bitbucket - eats their dogfood and has a "master" repo where everyone can submit issues: https://bitbucket.org/site/master/issues . Trello (mentioned above) dogfoods too https://trello.com/b/nC8QJJoZ/trello-development Fogbugz and Kiln are dogfooding too http://blog.fogcreek.com/dogfooding-until-it-hurts/ My company (sorry for being immodest) uses its own helpdesk software for.. uhm.. helpdesk https://www.jitbit.com/helpdesk/

So, +1ing this issue if it's still relevant.

[Healforgreen]

If Github has good reasons for not making an issue tracker, then so be it. I am neither for or against it, but having one would be more convenient and advantageous (in my opinion) than directly emailing them.

Covenience: Not needing to use an external application like Gmail or Outlook to voice a concern, report an issue, or submit a feature request.

Advantageous: An issue tracker would provide the ability to document the life cycle of a story, rather than having a trail of emails.

I am sure Github is abundantly aware of this, seeing that repos are centered around collaboration and self-documenting stories (i.e. comments), but I'd still like it to "be known".

[LinzardMac]

I get them not wanting an issue tracker, but a feature request / feature voting system would be AWESOME.

[tswartze]

There should be a button on each block of code with addition and deletions that lets you put the - or + in a gutter for easier/faster copying.

[barcher]

I don't really understand why the PR interface does weird capitalization things when ... really it shouldn't

This is a constant point of irritation to check syntax when copy & pasting to somewhere else. A thing is a thing is a thing.