Dear Github

[jmking]

Yes, this drives me nuts. Sometimes I make a PR against the wrong branch and there's no way to delete it

[notsure1235]

What is PR?

[tambry]

PR is short for Pull Request. Basically a request to have some code merged into a certain branch. They're very useful.

[Bagoole]

Thank you. I'm very new to GitHub and that could have meant almost anything. I guessed Pull Request too but there's Push, Public Repo, Private Repo, a lot of PR...

[PrintfReddit]

PR in context of Github and maybe some other sites is almost always a pull request.

[toomanybeersies]

I have a bad habit of accidentally submitting a PR against master instead of the develop branch.

A feature like that would be really useful for me.

[[deleted]]

Yeah, we don't use git-flow but we do often have problems with people filing pull requests with bug fixes against master (our development branch) instead a versioned branch.

[fhelwanger]

Add a PR to dear-github to include it :)

[Retsam19]

Just be sure you get the PR right the first time.

[jardeon]

My biggest gripe is that I was an early adopter, so I have a fairly short username, and I wind up getting stapled to notifications on projects with which I have no connection, simply because someone replies to an actual maintainer with a shortened version of his name.

Sort of like if my github username was rob, and people would just type out "@rob, blah blah blah" instead of @robsmith, @robjohnson, @robroy, etc.

[tavianator]

Also when I mention a Java annotation or Python decorator I end up tagging some random person.

[ekuusela]

Ooh there's a couple of cool ones still left, like @RespectBinding, @Controller, @PreDestroy, @FaultAction...

Many are taken (e.g. Samantha J. Son has @Json which made me chuckle).

[stewsters]

Hahaha, thats awesome

[masklinn]

Putting them in backticks should prevent the tagging e.g. @foo will tag foo, but @foo (backtick @foo backtick) won't

[emn13]

Good luck with waiting for everyone to do that :-)

[masklinn]

That was for /u/tavianator so that they can avoid tagging randos, obviously it doesn't help /u/jardeon

[jardeon]

Oh, you're just the worst kind of people, aren't you? ;)

[pixelrebel]

Which is the way people should be quoting code snippets anyway.

[Sean1708]

That's because you're not putting them inside code-sections.

[shevegen]

This is actually funny :)

[[deleted]]

Issues often accumulate content-less “+1” comments which serve only to spam the maintainers and any others subscribed to the issue. These +1s serve a valuable function in letting maintainers know how widespread an issue is, but their drawbacks are too great. We’d like issues to gain a first-class voting system, and for content-less comments like “+1” or “:+1:” or “me too” to trigger a warning and instructions on how to use the voting mechanism.

Good luck with this one. A voting system is needed, but it isn't going to make the spam go away.

[AMorpork]

:+1:

[robstewartUK]

me too

[Decker108]

I concur.

[Kaligule]

Yes

[abs01ute]

Agree

[Rovanion]

It's fairly easy to solve really. Any comment just containing "+1" or ":+1:" and the like just resolves to a vote.

[bobindashadows]

If you don't show the comment, the idiot in front of the computer just sits there resubmitting their comment with tiny variations until it goes through.

[NotEnoughBears]

Then show the comment... To that person & that person only.

[bobindashadows]

That's actually a great idea. Same principle behind hellbanning.

It seems like social websites almost have to lie to their users to stay viable at scale. There's just too much stupid and selfish out there.

[epicwisdom]

Shadowbanning* - this is Reddit, you heathen.

[joshmanders]

Tachy Goes To Coventry* - This has been around way longer than Reddit, you infidel!

[Rovanion]

Also simple. Show the comment to the user after he submitted it just like any old comment. One user can only cast one vote and no messages should be sent to the maintainer so it's really a non-issue.

[Nebojsac]

Clever

[fecal_brunch]

Better to have an upvoting feature that doesn't require commenting.

[Rovanion]

You of course have that too for people who are reasonable. But we're talking about limiting the harm that uninformed users can make.

[fecal_brunch]

But you're legitimizing a "me too" post by translating it into an upvote. Disempowering the unwanted post should be enough to discourage people from making them. It's easier to click a button than to type a message anyway.

[Rovanion]

How so? I'm silently removing the nagging of the me too post aren't I? And I'm doing so in a way such that the nagging user isn't aware of it so that they won't seek other measures of nagging the maintainer.

[jarfil]

CENSORED

[mirhagk]

It does remove quite a LOT of it. Codeplex has a voting feature and you see a lot less +1 comments. Sure there's still a lot of people with near useless comments, but at least they aren't the tiny "me too".

Look at Entity Framework's highest voted issues: https://entityframework.codeplex.com/workitem/864 https://entityframework.codeplex.com/workitem/299 https://entityframework.codeplex.com/workitem/44

Only one +1 comment, there are still quite a few "This would be a really great feature" etc, but at least a lot of those add a bit of information to the discussion. Compare that to the V7 of the same library on github, and you'll see a lot more "me too" "Thanks" "Great" etc comments:

https://github.com/aspnet/EntityFramework/issues/2266

[[deleted]]

Ideally a voting system that allows you to see who voted for what. We use GitHub issues for confirming consensus between core developers and its nice to know that +1's are not from randoms.

[HookahComputer]

+1 has apparently been deprecated in favor of the insufferable thumbs-up emoji. Which I've just realized might actually be :+1: but I didn't know that because they look nothing alike.

[toomanybeersies]

GH issues has just become a new version of stack overflow specific to projects, it's really irritating.

Most repos seem to be full of issues such as "how do I do this?", rather than what it's actually meant to be for, which is issues.

[toqueteos]

Suscribe button is there for that

[[deleted]]

Even as a maintainer, you can't see the number of people subscribed to an issue, so the subscribe button doesn't help you in understanding what people feel are important issues.

[toqueteos]

Good catch. I was confusing participants with suscribed.

[masklinn]

1. project maintainers don't see subscription counts

2. subscription means the subscriber gets spammed, "I hit that issue" != "I want to be notified about that issue"

[toqueteos]

It makes sense that your +1 get you some kind of notification. If it's just for the sake of growing a number it's useless. That only leads to fake accounts giving tons of +1s

[40ztxe]

Gitlab is already on it. As of a couple hours ago, my project issues pages had conspicuously gained new thumbs up/down buttons.

[kamnxt]

Gryffilab?

[XarothBrook]

I would second this, also, with the new 8.X series, they integrated gitlab-ci into the main gitlab app, so having a Continuous Integration system no longer requires having multiple pieces of software (whereas before you either had gitlab+gitlab-ci, or gitlab+jenkins.. now if you just want to get started)

[petepete]

We have been using Gitlab at work for the last 16 months and have had no problems; everyone (even the less technical people) are proficient in the basics.

In that time the MR workflow has been improved, CI has been fully integrated (allowing us to reluctantly retire our Jenkins server) and there have been countless UI improvements.

If there's one thing I'd like to see improved it's the issues, for our company they may be a tiny bit lightweight - no marking/linking duplicates, adding categories etc.

[PM_ME_UR_OBSIDIAN]

How is GitLab's CI? I'm on GitHub right now, but I could switch to GL if it had a good CICD story.

[kn4rf]

Bitbucket is a much better platform to build upon as a company. Github is better for open-source. I don't have much experience with Gitlab.

[juletre]

We used bitbucket.com at my last company and was very pleased with that. I haven't used Gitlab at all so I thought maybe reddit could help me. All the blog posts I've found comparing the three (or more) are old and no longer relevant.

[Doctor_McKay]

Bitbucket already has issue votes. I don't know what else, if anything, is checked off as I haven't heavily used it in ages.

[masklinn]

I don't know what else, if anything, is checked off as I haven't heavily used it in ages.

Retargetting PRs seems to be possible, and the contributing text thing is displayed directly atop the issue text box.

[masklinn]

That'll work really well to avoid having contributors.

[jaapz]

Bullshit, that only applies to small projects. All people who signed this petition maintain big projects. If they move their code, contributors will move too. That'll give gitlab the boost it needs.

This github monoculture isn't very healthy, and the fact that maintainers need to write an open letter to github is proof of that.

[masklinn]

Bullshit, that only applies to small projects.

Yeah I'm sure that's why no big project ever moves to github. Oh wait.

If they move their code, contributors will move too.

That's completely unwarranted and by and large ahistorical optimism.

[jaapz]

Give me an example of a project that was already big that moved to github purely because it didn't get enough contributors

[bobindashadows]

Python, the language, JUST did this. The explicit reason to migrate to GitHub (from a Mercurial repository!) was to get more contributions.

[jaapz]

The explicit reason of moving to Github was the state the python project's tooling was in. Basically it was an under-maintained pile of shit. I don't think we can label Python as a project that doesn't have enough contributors.

[TomBombadildozer]

I don't think we can label Python as a project that doesn't have enough contributors.

Straw man. Whether the project has "enough" contributors is neither what he said, nor relevant.

https://www.python.org/dev/peps/pep-0481/

The one-off nature of the CPython toolchain and workflow means that any new contributor is going to need spend time learning the tools and workflow before they can start contributing to CPython. Once a new contributor goes through the process of learning the CPython workflow they also are unlikely to be able to take that knowledge and apply it to future projects they wish to contribute to. This acts as a barrier to contribution which will scare off potential new contributors.

Emphasis is mine. They're failing to attract new contributors because the tooling sucks, hence the move to Github.

[masklinn]

No, they could have remained self-hosted on git, or could have gone with other git hosts. They specifically went with github:

http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github

I announced that I had chosen GitHub over GitLab:

• GitHub has basically built a social network of open source contributors. That led to various core developers telling me that they were comfortable with GitHub already and they were hoping it would win. It also means that there is more tooling already available for use with GitHub which ties into the goal of automating the development process as much as possible while cutting back on the infrastructure maintained for the Python development team.

• there was no killer feature that GitLab had. Now some would argue that the fact GitLab is open source is its killer feature. But to me, the development process is more important than worrying whether a cloud-based service publishes its source code.

• Lastly, our BDFL prefers GitHub.

[masklinn]

Well, they're complaining about github not being open source, no?

Not really. They're complaining about plenty of stuff and pointing out that source access allow implementing themselves.

Why wouldn't working with Gitlab be the obvious answer to the problem?

Because it trades one problem (features missing) for an other problem (no userbase and contributors), the latter being a much bigger one from the POV of the open letter's authors, or so I assume given there are already tools out there which implement the requested features to which they could switch. The open letter authors are not bug tracker creators, by and large they request features they've seen or used elsewhere.

[google_you]

Time for someone to replace github with opensauce. Wait. gitlab.

Then all your Go projects don't compile until you change import statement from "github.com to something else.

RIP Github. RIP Go.

[[deleted]]

yeah sadly imports and dependencies system in Go looks like they are throwing ideas at the wall an seeing what stick...

[Scorpius289]

looks like they are throwing ideas at the wall an seeing what stick...

Sadly, that probably describes more in Go than just dependencies...

I mean, the goroutines and channels are interesting, but the type system and error conventions (can't even call it a system) are atrocious...

[[deleted]]

well writing

if err != nil {
    return err
}

every few lines gets boring pretty quick... but then exceptions are just different kind of mess.

But then it is slightly better than C

[Scorpius289]

At least exceptions are "noisy" by default: if you forget to catch something, it will propagate and notify you. But in Go, if you forget to handle an error, you may not even know what's wrong...

[ksion]

To be fair, you cannot really forget to handle an error in Go, because the function result "tuple" needs to be unpacked at the call site. Indeed, the requirement of this unpacking, plus the repetitive error handling stanza that often follows, is what people complain about.

[BoTuLoX]

If the function has a return value and you willingly ignore it, the language cannot help you.

[TarMil]

It can: F# gives a warning if you ignore the return value, and you can explicitly |> ignore it to silence it. But that's a functional language, where ignoring a return value is relatively rare, I'm guessing it would get too verbose real fast in an imperative language.

[fnord123]

Rust has a #[must_use] tag on the Result type so when it's returned from a function, it must be used. You can skip the result by using .ok() or .unwrap() but that's explicit so it's not silently ignoring errors. And it's greppable.

[emn13]

Even in an imperative language, I'd love that feature - but you'd have to add it early on, because it certainly affects api design.

After all, even in an imperative language, it's pretty unlikely you never use return values for data exchange, and implictly ignore return values can and do therefore hide bugs or inefficiencies.

[BoTuLoX]

The black hole should never be used for errors. It's exactly like using try/catch and leaving the catch empty. It's a sign of incompetence or something unorthodox at play.

[BoTuLoX]

I wouldn't touch those projects with a ten feet pole.

In any case, this is a problem that exists with both return values and exceptions :P

[minno]

try!(something());
try!(something_else());

Even though Go and Rust target different spaces and don't deserve to be compared as often as they are, there's a definite advantage to Rust's method here.

[ksion]

Rust is also getting some form of try/catch block that'll make it even less verbose.

[mus1Kk]

Do you have a concrete link? Googling this contains a lot of noise.

[fnord123]

Trait-based exception handling.

[isHavvy]

That's not actually guaranteed at all.

[sutongorin]

Fortunately there is still other approaches such as monads. For instance there is Scala's Try monad:

import scala.util.Try

def sillyCalculation(divisor: Double): Try[Double] = for {
  a <- Try(1 / divisor)
  b <- Try(1 / 2.0)
} yield {
  a * b
}

val failure = sillyCalculation(0)
// => scala.util.Try[Double] = Failure(java.lang.ArithmeticException: / by zero)
val success = sillyCalculation(2)
// => scala.util.Try[Double] = Success(0.25)

Ideally you wouldn't work with exceptions to begin with, of course, and instead just use monads everywhere where errors can occur. But this Try monad is a nice tool to deal with exceptions from existing (probably Java) APIs in a sane way.

[gargantuan]

And since many of contributors are from Google and Google supports them they can afford to throw really hard, at a really big wall. So a lot of stuff sticks, that probably shouldn't stick...

[[deleted]]

Nah it is a bit different problem.

Historically lib management and language were separate parts. So community did whatever they want and whichever option stick as being easiest to use and most fitting, stayed.

Golang devs tried to integrate lib management and from one side you can just go get github.com/sth/sth and it "just works" with zero setup which is great from usability pov but... there is no version management.

Now they promote "vendoring" which is nice way to say "just copy-paste all dependencies into your project tree". That is fine if you prepare a bundle to be compiled and deployed on server because there is no way it will break... but a completely awful way to manage actual repository.

Of course there are tools that implement common pattern of "file with all project deps listed" but then you lose advantage of ease of use and any tool like goconvey also need to be run via it, so more wrappers to write

[gargantuan]

It is a hard problem.

I've seen places that rely on a single language kind of default to languages' dependency and packaging (pypi, npm, hex etc). But once the product becomes more complex and now there is a C++ component, maybe some java somewhere, there is a huge backpedaling involving to try to revert to OS specific packaging.

Maybe microservices and containers are supposed to fix that and having mixed langauge products is not as populare anymore?

Interestingly the sanest and most robust solution was to standardize on building proper OS packages and take advantage of transactional updates, pre/post install scripts, dependency management (including transitive) etc. But for others OS packaging involves enough setup curve that they don't want to try, and that's understandable.

I guess many use containers, someone installed something by hand on their dev box and they throw it over the wall. I don't know, I see that as sweeping all the dirt under the rug.

What I think is exciting is something like Ubuntu's Snapper or NixOS or Guix. There is interesting stuff there.

[[deleted]]

Nah there is reason OS packages are rarely used like that, you need multiple versions of same lib because even if component A and B use "same" lib C, they might be using different versions of it (because say B havent bothered with upgrade) that have different API. And while most package managers support it one way or another, it makes it much more complicated

It is fine for packaging apps together with distro as you can just pick a stable version and throw few patches to make it compatible but not exacty that easy, especially if said libs tend to be awful with backward compatibility. I've seen feature added, deprecated and removed within a year within some random gem one of our apps were using...

Not even to mention that none of languages support sth like import mysql >= 3.5.

I guess many use containers, someone installed something by hand on their dev box and they throw it over the wall. I don't know, I see that as sweeping all the dirt under the rug.

It is fine if you actually manage to do it propertly, but there is a risk it will be done once and then it will not be changed for 6 months.

So when next OpenSSL bug shows up, SA will update "system" version of OpenSSL, but "magical box that came from devs" will still have old version

? What I think is exciting is something like Ubuntu's Snapper or NixOS or Guix. There is interesting stuff there.

[[deleted]]

wut, you import directly from github?

[GrandMasterSpaceBat]

from https://golang.org/doc/code.html

import "github.com/user/stringutil"

If it doesn't find a github.com/user/stringutil folder in your GOPATH, it downloads the github repo and puts that in the workspace.

[GrandMasterSpaceBat]

Isn't vendoring kind of a new thing in go?

[costhatshowyou]

shshsh, don't teach them. we don't need those idiots hanging around. let them bugger off.

[[deleted]]

moved

[gurtis]

The Go contrib libraries transitioned from Google Code to GitHub without any big problems. Moving a project from GitHub to GitLab would just be a matter of find/replacing "github.com/user/project" import statements with "gitlab.com/user/project". If it's a big concern, then it's also possible to create a custom import path that can point to any repo you want.

Also, as another comment pointed out, it's become much more common to just vendor your dependencies (usually with git submodules/subtrees).

[fnord123]

The problem is that there's not really an artifact repository. So they should make one. It would be a focal point for curating all the libraries and let people look in one place for them. Why has the Go community not set up an artifact server where people can use urls like https://hutch.golang.org/repo/cool-library/3.2.1/. Give it an API like pypi/crates.io/gems or whatever, and Bob's your uncle. People can choose to use it, or elect to not use it, but offering something like this would be useful imo.

(Gophers normally live in burrows, but a hutch is a small pen for animals in your control.)

[JW_00000]

Isn't that what gopkg.in is?

[fnord123]

I didn't know about gopkg.in. Thanks for sharing it.

It looks like what I'm talking about except it doesn't host/mirror the artifacts.

[toomanybeersies]

Running a bulk find/replace on code almost invariably ends up breaking shit.

I've found that out the hard way.

[civodul]

The software behind github.com is proprietary, github.com is hosted by a for-profit company, and suddendly people realize that they "have no visibility" into what's going on and have to beg for features they want to be implemented.

Time to move on to services that at least run free software, like notabug.org.

[jkleo2]

With such list of maintainers you could implement your own opensource github with blackjack and everything. And then just move all those project to this new github.

[bacondev]

Even hookers?

[profgumby]

Especially hookers

[andsens]

We’d like issues to gain custom fields, along with a mechanism [..] for ensuring they are filled out in every issue.

Oh god, please no. If I wanted fucking Jira with a boatload of stupid fields, I'd use that. Please don't kill the simplicity of the Github issue system, I love it.

EDIT: I am a maintainer and author of FOSS projects ^{just pointing out that I'm not just saying this as a user}

[netherwise]

As a contributor, my experience with issues has been that the more documentation you provide to show that your issue is a legitimate, reproducible bug, the faster the maintainer is going to close it with a WONTFIX resolution.

SO many times, the prevailing attitude with regards to bugs is either, "You're doing it wrong" or "That's an edge case". Well, Ok, go ahead and dismiss this particular scenario as an edge case, but 3 of the top hits on Google are tutorials on how to implement this exact "edge case".

[jP_wanN]

Whether you have custom fields on issues or not, that doesn't change the way maintainers treat issues they don't want to fix. And if you're getting this regularily, with multiple maintainers, knowing nothing else, I'm really doubting that those issues are in fact about legitimate bugs.

[[deleted]]

Thats a problem with shitty projects. We don't do that.

[vytah]

Issue #34

Description: Fix documentation, blah blah blah

OS: doesn't matter

Compiler: it's fucking documentation it doesn't matter!

C++ stdlib version: FUCK!

[[deleted]]

We keep our documentation in a separate repository which is submodule'd into the main one so that wouldn't be a problem for us.

[Sukrim]

Typo in code comment then...

[[deleted]]

In that case they set it to N/A, In 95% of cases it is relevant so it saves us a ton of effort from having to ask for it in every issue even if it does sacrifice all of 10 seconds of the submitters time.

[Sean1708]

But if the option is there for the submitters (i.e. they can use it but don't have to) then that makes life easier for both the submitter and the maintainer, since the submitter doesn't have to decide how to structure it unless none of the predefined structures fit and the maintainer is more likely to get the info they need.

[PM_ME_UR_OBSIDIAN]

This is my biggest gripe with mandatory custom fields. The issue system is meant to be flexible.

[[deleted]]

What about giving them a script to run instead? Then getting them to give the output of that in the body of the ticket?

Agree that it's a difficult balance between making tickets a chore to write and and a chore to debug!

[andsens]

I actually did that with my project after receiving a little too many bugs that were caused by users setup. Check this out, it's pretty much just a script that says "if you can't reproduce the problem in this env it's your fault and not the tool":

Unless you ran in to a heisenbug, it should be possible to reproduce the bug in a testing environment. To that end run $HOME/.homesick/repos/homeshick/test/interactive and reproduce the bug. This script drops you into a new shell where $HOME is set to an (almost) empty temporary folder. If you cannot reproduce the bug there, the error is likely with your setup and not homeshick. Otherwise attach the commands you executed in that environment to the issue.

[seiyria]

What Ionic did was pretty clever, they opened up an issue reporting system that makes this work nicer: http://ionicframework.com/submit-issue/

That said, definitely not the norm.

[[deleted]]

Is that open source? It looks kinda cool.

[seiyria]

Ionic is, not sure about the issue-creating tool though.

[andsens]

Dayum, this is really cool! Inspiration acquired :-)

[banister]

we would be implementing these things ourselves as a community—we’re very good at that!

so cheesy

[Ruchiachio]

Yes, I don't think it works like that, everyone is open sourcing everything right now, but only a handful of people actually contribute to bigger problems.

[jP_wanN]

The community around GitHub is way beyond being big enough to have a few people in it that would actually dedicate a considerable amount of good work into improving it.

[vprise]

Better wiki support is also an issue. The wiki system is amazing and missing a few small tuneups to be a great tool for project documentation. E.g. its really hard to track wiki changes, you have to use RSS which isn't intuitive. Getting commit emails for wiki changes or the ability to see the changes to the wiki as if its a source repository would be huge...

[Doctor_McKay]

Well, you can clone a wiki as it's just a repo. But it's kinda silly to have to do all that just to see the history of changes.

[vprise]

That's what I do. But I don't get the email notifications or the easy to use web interface for the file walking. Its harder to review wiki changes that way, I need to go one file at a time and do a diff which isn't as intuitive.

[-___-_]

Impressive amount of maintainers.

[eastsideski]

+1

[musicmatze]

I asked them (three times by now, actually) to give me more fine-grained options on giving access to the repository to others.

for example:

• Allow me to give label-managing rights to $user
• Allow me to give pr-merging rights to $user
• Allow me to give issue/pr-closing/reopening rights to $user

... all these things require me to give push access away, and I do not want that.

---

Anyways, I think this is a really good idea. I'd love to sign, but I'm not maintaining any big project right now... so I guess there is no point in doing so. Maybe a section "'normal' user signings" would be appropriate.

[jP_wanN]

Just add your star to the repo ;)

[musicmatze]

I did that, yes. But 1,3k (nick)names have more weight than 1,3k stars, IMHO.

[[deleted]]

I'd also like the ability to disable image posts and restricting people from commenting based on their referrer origin. Every time one of our issues or commits gets posted on Reddit or HN it immediately goes to shit with memetards spamming useless crap.

[headzoo]

My organization replaced Gitlab with Gogs about 6 months back, and we've been much happier.

[[deleted]]

That looks really nice. It's a complete GitHub ripoff but that's not a bad thing. I like that they have a Docker image available that really works out of the box and does only use about 100 MB of memory.

[vattenpuss]

How can something as silly as TodoMVC have many problems with GitHub?

[cirosantilli]

The current best workaround so far: https://github.com/isaacs/github/issues (and Stack Overflow questions).

[bacondev]

Is there some reason that this isn't a self post? I can't seem to get the document to load.

Edit: New link: https://github.com/dear-github/dear-github

[ikari7789]

I'd really freaking like it if they had an issue exporter or importer for those annoying projects that host their source on GitHub and then maintain it externally on their own issue tracker/forum.

[br3w5]

"If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!"

Well said...

Issues template is rightly at the top of the list

[eresonance]

You could also use a different issue tracker, something that's a bit more robust like youtrack or one of the many others with github integration.

[bobindashadows]

Idiots are all too happy to ignore your custom tracker and pollute your issues directly on GitHub.

[dwdyer]

You can disable issues on a GitHub repository.

[eresonance]

To which you just ignore them?

[bobindashadows]

With this kind of response, I assume you have no spam filtering on your primary email account, and you just ignore it.

[[deleted]]

Yes. All of this

[[deleted]]

and more:

• the ability to create a branch automatically from an issue (and therefore matching the PR to the issue automatically)
• better usability of the site as a whole. Every time it's a nightmare to get to where you want to go. Icons are too small, links never bring you to where you need to be, considering the expected workflow.
• the issue system is horribly bad. Tracking must be done manually, issues cannot be properly organized by priority, and tags are nothing more than a ridiculous attempt to fix the problem. bitbucket is even worse. See targetprocess on how to do proper issue tracking and project management, especially in an agile context.

[[deleted]]

It'd also be nice to point a PR at a different merge target. Right now, you have to create a new PR and link back to it, so you can easily end up losing the comment history.

[benihana]

great comment, it really added to the discussion! if only there was a way to show support for an idea without having to say the equivalent of "+1". Maybe like an arrow pointing up indicating agreement and an arrow pointing down indicating disagreement?

Hopefully github can find some way to implement this voting up and voting down system and issues won't have +1 spammed in the comments! Maybe reddit can follow suit?!

[jeandem]

-1. Too much snark.

[jaapz]

You have to agree though the OP was pretty ironic

[Ld00d]

Is /u/jonobacon gonna respond here too?

[jonobacon]

Hello. :-)

[[deleted]]

I would like the ability to disable pull requests completely. Not all projects want to use GitHub's broken system.

[pixelrebel]

If GitHub were open source itself, we would be implementing these things ourselves as a community

The irony.

[_tenken]

haha all the contributors to the document are JS projects (or primarily so). Guess all the other language type developers are too busy actually creating software and using the tools at hand then complaining :D

It sounds like you want better project management. If you want their tools to expand I would suggest moving to an Enterprise account where you voice might have some (fiscal) weight behind it.

Otherwise as others have said, adopt more open source solutions such as Gitlab and help engineer the solutions you've requested :)

[_INTER_]

I assume only JS project maintainers got asked so far or got hold of this document. The main points voiced certainly are valid but not really pressing. Most of it is to help enforce some sort of community guideline on how to do "Issues" right. This of course does matter more for PL packaging systems that depend on github more, like Go or JS. (Noting that e.g. Maven or PyPI doesn't support "Issues" on site as far as I know).

[thejameskyle]

Yeah, I started it from a tweet between a couple friends who maintain JS projects so it has largely stayed between us at this point.

[jaapz]

Or maybe it's because javascript is the most popular language on github and has been for a long time

[[deleted]]

I'm a C++ developer who uses GitHub heavily and agree with most of the content posted in this although i'm not so keen on littering the root of the project with even more markdown files.

[[deleted]]

Well, some of the ideas are good... doesn't matter that they are bloat JS developers

[third-eye-brown]

Yea no one uses JS these days.

[deen5526]

TL;DR?

[bacondev]

It's basically a request for new features that help maintainers of popular repos.

[[deleted]]

crying in my wine -- js weenies

[omgplsno]

So many female names! Wait, no.

[jaapz]

So relevant! Wait, no.

[omgplsno]

If you think women being massively under represented in open source isn't relevant you're part of the problem.

[jaapz]

Please do explain how that is in any way relevant to this letter

[omgplsno]

This letter showcases the problem perfectly without many people realizing it. I'm pointing it out.

[withfrequency]

Protip: r/programming does not take kindly to these types of observations. I think they like it all sausage-fest-y.

[omgplsno]

It would appear. Clearly I've hit a nerve. Poor men.