My name is Jono and I started as Director of Community back in November at GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in.
Firstly, thanks for your feedback. I think it is essential that GitHub always has a good sense of not just what works well for our users, but also where the pain points are. Constructive criticism is an important of doing great work. I appreciate how specific and detailed you were in your feedback. Getting a good sense of specific problems provides a more fruitful beginning to a conversation than "it suxx0rs", so I appreciate that.
I am still figuring out how GitHub fits together as an organization but I am happy to take a look into these issues and ensure they are considered in how future work is planned. We have a growing product team at GitHub that I know is passionate about solving the major pain points that rub up against our users. Obviously I can't make any firm commitments as I am not on the product team, but I can ensure the right eyeballs are on this. I also want to explore with my colleagues how we can be a little clearer about future feature and development plans to see if we can reduce some ambiguity.
As I say, I am pretty new, so I am still getting the lay of the land, but feel free to reach out to me personally if you have any further questions or concerns about this or any other issue. I am at firstname.lastname@example.org.
My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other people with the same frustration , but we have no idea how to get that on GitHub's roadmap.
Perhaps if Github used their own issues system to gather feedback on Github itself, they'd more rapidly improve it. I'm sure they'd feel a lot of these pain points in a far sharper, more visceral way if they were subjected to them daily.
Open source ties in with my work. Every one of my private repos has open source dependencies hosted on github.
Privileging the priorities of my private repos over their public dependencies would be shortsighted.
I think that’s Github’s call, but I definitely don’t disagree with you and apologize that I came off that way. Open source projects exposed me to Github and greatly benefit the projects I work on in private repos. I really do want those projects to have an effective platform for growth and stability. I don’t want to water down their needs; I just wanted to offer some balance to the discussion.
My point was simply that this probably isn’t something that is as easy for Github to solve as it may appear on the surface. Any changes they make to the issues system can’t upset the low friction way it works for repos with a modest amount of contributors (and +1’s from clients are appreciated). I hope that positive changes come out of this letter.
If Github were to leave Open Source projects high and dry, they’d lose my business.
But you're the huge majority of people who give GitHub money. It makes sense not to prioritize the pain points of open-source projects when you lose money by hosting them.
We only chose GitHub because we wanted to host our open source repos there. If they don't prioritize the open-source projects then we have no reason to pick them over BitBucket or something else like that.
Much of that is due to the OP's requested features that are currently missing. But tbh, it is too late to get us to switch.
> Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.
For instance, is something we basically implemented in our local version of GitLab but aren't sharing because our implementation pulls this from internal docs other people can't use. Our CSRs put issues into GitLab but they tend to forget steps while on the phone with a user.
We wouldn't have bothered if we had something like this when I was evaluating GitLab vs. GitHub.
I also have a public account that I use for contributing to public projects so it could also help to avoid duplicate accounts in search results.
All accounts should be searchable for username/real name with GitHub's search anyway.
Your private repo's and contributions are not made public, so there's no "risk" involved.
Huh? Github isn't opened sourced so how is a different fashion from anyone else using private repos?
Users can use those buttons to +1 or -1, and any comments that contain nothing but an emoji (like `:+1:`) are automatically converted to emoji awards, as we call them.
What I came up to work around this is:
- Create an org named <YOUR-USERNAME>-deprecated
- Move the projects to the organization
- Set the avatar of the organization to your avatar, with desaturated colors (purely cosmetic, optional)
Another good example is harthur's "[UNMAINTAINED]" 
I search and then i see it in the title.
Better would be an Option in Github to set a project to unmaintained or deprecated, with an optional link to the new project (if some exist).
Github could then change the background color from white to an other color or add a border around the page, so that it is really obvious that this project es EOL.
ATTENTION: Please find the canonical repository here:
What this tells you is that enough people are not only using this repository, which was last updated in August 2014 with a change to the README directing people at the new source, but people are giving it stars this week such that it shows up as "trending" higher than the correct repository.
There has to be something wrong with the deprecation process if this happens.
Aye. Some folks in the discussion linked to by krschultz complain that "People sometimes don't read the README and -thus- don't notice deprecation warnings.". To them I ask: "What makes you think that those sorts of people will notice anything less than an overlay that prevents them from interacting with the Github UI for that particular repo?".
Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right?
> ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings]
More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths
Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) 
> ...coordination between go and github could implement something for deprecated repositories without changing anything in git.
A couple of things:
* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.
* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)
* Frankly, having a well-known file in your Git repo that contains meaningful tags seems far more compatible than changing git, or altering the $BUILD_TOOL<->GitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)
 Thanks for the documentation link, BTW! :D
The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Facebook/Uber.
So, I heartily agree that vendor lock-in is bad.  However, git doesn't handle mailing lists, or issue trackers, or hands-off repo push access control, or.... So, if you're going to do more than just serving git repos, you're almost certainly going to have to do these things yourself, and you very well might end up doing them in a way that differs from how everyone else is doing them.
I mean, as long as you can get complete exports of the data in the important non-git bits, who cares, right?
 I'm STILL mad about how Hangouts turned out.
I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many. Whoever decided it was OK to depend on that library should be able to follow it closely enough to say when it cannot be depended on.
There are a lot of "if's" and many things might go wrong -- there's almost never 100% guarantee, but every mean that makes end product more reliable is a good idea.
"I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many."
Such number of dependencies is common when building custom Kernel/OS + application. Also, I've never mentioned direct dependencies, some are just tools to build tools. It wasn't event that big of a project -- a relatively small (~150 Mb) custom OS with Qt application for an embedded device.
Anyway, a good example of a successful feature request – shared since it might help others in their quest for success – included me attempting to reduce the problem, scoping it and suggesting a solution. If you can find examples of this problem over multiple open source repositories (in my case nodejs) it seems to contribute to it getting fixed.
- Note the feedback.
- Bring in the right folks to consult with on your end.
- Write a public response with concrete information (should be first interaction).
- Finally, reach out to the authors of this post. Perhaps, getting them more clarity on your roadmap and your thought process will go a long way in resolving matters like this with high profile maintainers.
The next step, as you mention, is to bring the right people in. This is why I want to ensure this is raised with our teams inside GitHub to explore ways to rectify some of these concerns.
Linode could take a leaf out your book in terms of dealing with people not entirely happy (if I'm been kind) with the way they deal with stuff.
At present, I’m not sure how this response is different from the "empty response" that motivated the publication of this document in the first place, except that this response is also public. Comments like "happy to take a look into these issues", "considered in how future work is planned" and "ensure the right eyeballs are on this" uses a lot of words to say nothing. If the community department is not the right place, maybe it’s time to walk over to where the the product group sits and ask. They probably read Hacker New too.
I’ll also highlight a possible theory: the right people at Github have already looked at these requests and decided that is not what Github Issues is for. Perhaps Issues is prioritized for the masses, not the small minority of very popular projects (but not resourceful enough that they have staff). Each of these feature requests do add friction (if only in complexity) and the majority of projects that do not need and should not utilize them. Hopefully someone at Github will quash this theory but it is consistent with events so far.
Why not have the option to enable issue voting? It could be as easy as stars for issues.
Custom issue instructions would be trivial to tuck away in the settings page or associate with a specially named markdown file. They turn a wiki on by default, but you can't instruct users about the info you expect in their issue on the page where they create the issue. Documentation is very effective when it is inline with the system it is describing.
Custom issue fields with validation is a little more complex. Punt.
When people submit your issue tracker to hackernews/reddit/twitter all hell breaks lose and time gets wasted for nothing.
1) apologizing for being new
2) extending borderline patronizing praise (the OP likely wanted a response to the issues put forth, not your approval)
& 3) a promise, which you can't necessarily keep, to put eyes on the issue instead of speaking to the issues raised directly.
It's not what I would expect from someone in that role at that sort of company. It's, unfortunately, what I would expect from a company that had the sort of issues raised by the OP.
Edit: Essentially the same as reported here: https://github.com/isaacs/github/issues/268
Here are some of my fave :+1:-a-thons that help demonstrate when the issue system starts to be less useful, and the Github acknowledgement seems sparse:
Also, you might consider empowering your social media team. I see Github as a pretty cool company. And when I sent this tweet, I was expecting to have a bit of a shared chortle with this tweet as I know I would of had with @SlackHq:
But instead I got nothing, except a vague sense of having offended someone (sorry BTW, it was only a joke! :'()
Similar to the way twitter provides verified accounts maybe
GitHub should consider a tagging these popular repositories to allow for more advanced control over the collaboration project.
When I first read the letter I was a little bit disappointed, one thing I've enjoyed (to an limited extent) is the low barrier of entry to pull requests. The spring boot team especially are extremely patient and understanding when it comes to pull requests.
Hopefully there's enough community will in this to encourage GitHub to make the change, if it does really come down it not being worth the money it would be a disappointing sign.
* Are "we" in such a huge hurry that we don't look at our scrollbar to see if there's more to the document that we're viewing?
* How did "we" get so incurious that we don't even attempt to scroll down to see if there's more information to read?
I mean -seriously- the intended audience for this particular open letter is technical people.
After re-checking the link:
Ah! See, the document that you are looking at is hosted on Github. At the time of my comment (~six hours ago), it was a two-printed-page document hosted on Google Docs. dang comments here: https://news.ycombinator.com/item?id=10907271 (four hours ago) that he changed the link from the Google Docs document to the Github document.
(And now that I know that, the wave of downvoting makes a lot of sense. (even though pvorb explicitly says that he's looking at a document hosted on Google Docs))
And yes, most of the time "we" are in such a hurry. At least I am most of the time. Time is limited.
Given many open source project adopting it for their code repository its important question to be answered.
Otherwise sourceforge.net story will repeat again, this time with github. Many projects adapted it when it was closed source and then when they open source it slowly and later due to falling revenues just started crumbling.
And gitlab is now 99% feature-compatible with github. If you aren't using the developer ecosystem of github.com, you are not missing much using the free software option already.
> We’ve gone through the only support channel that you have given us either to receive an empty response or even no response at all. We have no visibility into what has happened with our requests, or whether GitHub is working on them.
I'd like to call out that the GitHub user @isaacs maintains an unofficial repository where the issues are "Issues for GitHub". It's not much more than a token of goodwill from a user to open a place like that to organize bugs (GitHub: you are lucky you have such a userbase!), but it's the best thing I know of for "has someone else thought of this?". Many of the issues that have been filed there are excellent ideas.
: though I'd say if you also think about it, you should also go through the official channel, even if just to spam them so they know people want that feature.
Gitlab is an open source repository manager that supports local installs as well as public hosting at gitlab.com. If author appreciates open source, perhaps they should put their efforts into improving an existing open source option rather than relying on a proprietary solution.
I cannot fathom why people are still actively supporting GitHub.
Even if you ignore the ethical reasons, which if you are an open source developer really should suffice, GitLab is better and more customizable in every way.
Supporting it benefits yourself and all of the FOSS community.
Really? I find that hard to believe, but it makes me glad I use Mercurial if that's the case.
But gitlab/github are more than just git repositories -- issue tracking, discussions, wiki, etc. One version control which includes most of this as part of the repository is fossil, http://fossil-scm.org
GitHub used to bill itself as "Social Coding", but the "Network" graph has not seen ANY updates since its original introduction in April of 2008. Issues has seen very few updates. Even the OSS projects that GitHub uses internally have grown stagnant as GitHub runs on private, internal forks and maintainership passes to non-GitHub-employed individuals (e.g. https://github.com/resque/resque/issues/1372).
The word "Social" no longer appears on GitHub's landing page. They're chasing some other goal...whatever it is.
I've been puzzled for a while with what github is doing hiring so many social impact employees.
Maybe something more noble than a social coding site?
Maybe something more noble than a social coding site?
They seem to think they're too big to fail.
 - https://github.com/FeministSoftwareFoundation/C-plus-Equalit...
 - https://github.com/ErisBlastar/cplusequality
 - https://bitbucket.org/FeministSoftwareFoundation/c-plus-equa...
 - https://code.google.com/p/c-plus-equality/
That is a very good thing. At this point in time we're beyond speculation. We have some good evidence about the direction online communities take with and without content moderation, and the serious players (most recently Reddit) have come to realize that top-down moderation is absolutely necessary. Fringe, unmoderated activity has a place, but it is outside mainstream platforms.
I don't understand what the problem is. In anything -- from TV to theater, music, architecture and social clubs -- there is the mainstream and the fringe. Maybe one day, fringe ideas will become mainstream and maybe not, but as long as the fringe is fringe, it is usually not part of the mainstream. It's pretty much a tautology. The Wire was a superb TV show -- possibly the best -- but it just didn't belong on the broadcast channels. It wasn't censorship (not that I'm suggesting that sophomoric misogynistic jokes are anything like The Wire, but they have no place on GitHub).
Sorry my friend, that is majority rules.
The problem is we already know what this form of thinking eventually leads to. It's happened several times throughout human history. The problem is one group feeling they have the power to dictate to the "other". Especially when the group dynamic and what is considered other changes frequently, leading to more and more problems.
You don't even need to read history. Just take an objective look in various areas of the world, and culture, today and you will see it.
What you consider your mainstream ideals today may be somebody else's fringe tomorrow. Such as some of these supposed "misogynistic" projects that were using age-old terms that someone recently decided was wrong because they want to somehow change the context of the usage of words. When this happens to you, and it eventually will if the pattern continues, hopefully the group in power will be nice to you.
Nobody is dictating. Do whatever the hell you want. Just don't put on an off-Broadway shown on Broadway. That's it.
> What you consider your mainstream ideals today may be somebody else's fringe tomorrow.
Sure, but that doesn't mean you NBC should broadcast Oz. That's what HBO is for (again, I'm not comparing HBO with misogynistic communities or that I think misogyny would become order of the day; but even vile ideas have their place). People know that broadcast TV has certain rules and certain audiences, and if you don't want to follow the rules or address that mainstream audience, your show will not be aired on broadcast TV. You want to call that censorship? Fine, but as long as those "censored" opinions have 100 other cable channels that will air them, that's perfectly fine by me.
> that someone recently decided was wrong because they want to somehow change the context of the usage of words.
BTW, as a former student of history I can tell you that people always decide to change the context of the use of words in order to make society better (of course, what they think is better). And this pattern is never restricted to just one political group. It is just that political groups always find the others' new contexts annoying.
I'm assuming you're not suggesting that since people "always" change the context on the usage of somebody else's words that it's an acceptable thing to do.
No. What I'm explaining is not how the majority opinion is treated, but how the minority opinion is, namely, it is not blocked. Majority rule could also mean that the minority is barred from voicing their opinions, but that is not the system I'm describing.
> Again, it's an excellent system as long as you agree with the majority.
I don't know about excellent, but it works well well even if you're not. I can't see how society can operate if every opinion -- no matter how fringe -- is given the same prominence.
Personally, I don't know if research shows open-source code-of-conduct helps curtail the very real, very serious problem of online-community marginalization (I have seen research on that) or not, but I'd rather defer to the experts, and in any case, it's worth a try. Just as code should be written by expert programmers, community management should be directed by the advice of social experts. Again, I don't know if this is backed by research or an experiment in itself to see if the approach is effective, but I'd rather trust people who devote their lives to studying the issue than to programmers who just "feel" this is wrong. If programmers want to run their own communities and not rely on the advice of experts, they're welcome to do it outside the mainstream platforms. If their approach works better to decrease marginalization, I'm sure the experts will take it to heart.
With regards to who should be trusted to manage communities, I'm afraid I can't convince myself to believe in the experts. In most cases, these "experts" are not people who have successfully managed communities or are even particularly well educated on how they work; they are self-appointed thought leaders with, often, fringe agendas and little concern for who gets trampled in the process of enacting them. They are generally the last possible people you would want to put in charge of anything.
>. If programmers want to run their own communities and not rely on the advice of experts, they're welcome to do it outside the mainstream platforms.
Not if the "experts" do everything in their power to marginalize and poison the public image of those non-mainstream platforms, unfortunately. I think it was either Scott Alexander or one of his commenters who pointed out that, if you take over a community and impose anti-witchcraft policies, you can then easily dismiss any alternate communities -- with a certain amount of accuracy, even -- as being full of witches.
Why not? I mean I can see how the "victims" wouldn't like it, but a society without any such form of influence is a society without interaction. For example, one person living in an empty world can be completely free (within their abilities), but two (or more) who may interact cannot. Either you allow one the freedom to restrict the other's freedom, or you limit both persons' freedom to exclude mutual freedom-limiting actions (by whatever means, be they forceful enforcement, internalized ethics or any other). The best you can do is manage freedom to some mutually acceptable level.
As the accusation directed towards those "free" programmers is precisely that they marginalize others (and contrary to the insistence of some of those programmers, that accusation is backed by actual data), this "persecution" is the best means we have curtail their behavior (unfortunately they are not persuaded by other means), and since the framework of our society allows this form of persecution but not actual punitive legal actions, it seems quite fair to me. Further restrictions against such persecution would naturally cut both ways.
So, given the current legal framework where marginalization is legal but may of course have social consequences, those developers would just need to be tough and bear them, which is pretty much what they say their own victims should do. Then why do experts prefer the well beings of some marginalized groups over that of exclusive programmers? Well, as any form of full or partial freedom-restriction works both ways, the thinking is that social groups with less power deserve more protection. Obviously, no one like to be marginalized in any way -- even the more powerful members of society -- but if someone must be hurt, we prefer it to be a group that will suffer less real damage.
In any case, if you prefer that such persecution would be prohibited with more forceful enforcement (say, legal), I'm sure that could be arranged, but I'm not sure those programmers would like the result any better.
> Well, as any form of full or partial freedom-restriction works both ways, the thinking is that social groups with less power deserve more protection. Obviously, no one like to be marginalized in any way -- even the more powerful members of society -- but if someone must be hurt, we prefer it to be a group that will suffer less real damage.
Bit of a tangent, but if you deliberately wanted to create furious opposition to your policies there's no better way than to put unequal protection front and center. "Everybody should be protected from X" is a winning policy. "These strangers over here should be protected from X, but not you" is, to put it charitably, not.
What proper mechanisms, then, does society grant the victims of weak-group-marginalization to fight their own marginalization? You're suggesting that even drawing people's attention to it is wrong.
> Bit of a tangent, but if you deliberately wanted to create furious opposition to your policies there's no better way than to put unequal protection front and center. "Everybody should be protected from X" is a winning policy. "These strangers over here should be protected from X, but not you" is, to put it charitably, not.
Unequal protection is already present everywhere. It is not binary (neither is it in this case), but it is very much at the core of modern democracy. The idea is that different people benefit from society to different extents or are harmed by society to a different extent, and therefore the taxes they need to pay or the investment they get from society should reflect that. Victims of a crime -- say theft -- are eligible for restitution, while people who are not victims, aren't. The idea of unequal protection in this case is that some groups are victims to unfair exclusion, and correcting that exclusion is fair.
But I'm pretty sure you wouldn't endorse a policy where, say, white victims of theft are entitled to restitution, whereas black victims are not. That's what is all too frequently proposed by the "experts."
GitHub is (or should be) just another Git hosting site/Web frontend/misc. integration with other software project's concern. It should be relatively simple to just choose another website. If we've gotten to the point of saying that they are 'regulating the content of open source projects', we've already failed by making GitHub too important.
I don't want to assume any motive to your comment, but I think it would be a cause for concern if the world at large assumes that women/minorities are hired strictly for their "social impact".
Github is a trailblazer here for tech companies taking social impact seriously. There is nothing derogatory about it. They do amazing projects in this area
I was merely curious about how this fits into their grander strategy.
I wonder if threads like this keep popping up if people will say "Fuck it" and build an OSS Github clone that focus on being the Reddit of Code/Git rather than another Version Control Enterprise product.
I'd do it but I'm an asshole, not a community builder.
Since I'm in the edit window and its complaining I submit too fast:
Tbh, the problem with Kallithea SCM and Trac is they aren't really built to generate network effects. They both suffer from the same problem as literally every other unsuccessful Github competitor has:
1) You need something built to generate a network effect first, other considerations second, to successfully compete.
2) You need to then leverage that network to chase Corporate money.
GitHub seems to be neglecting #1 in favor of #2 and that imbalance is an opportunity if someone can exploit it. However, that requires someone who is good at being a community builder rather than a software dev.
I hope they change the decision to support one of the project like Kallithea or trac by migrating their system and build network effects.
This isn't how it works. You don't help projects by pretending the football-stadium-sized issues with them don't exist and using them despite their flaws.
Trac is an awful, awful piece of software. It's awful to set up, to use, to maintain, to gather feedback from, it's awful for just about everything. If in some very weird parallel universe it gathered even 1% of the following that Github has today, you'd find a 20 page google document at the top of HN about its issues.
This is me being nice. Kallithea is a lot better, but it's just a far poorer Github-like clone. You might as well use Gitlab.
The other advantage of Github is the network effect. You don't have to create yet-another account, which removes a barrier to contributions.
When you're an open source project, you can think of the "Submit issue" button as your payment form. Same UX rules apply: The user must be able to file the issue as easily as possible. You should not throw obstacles in their way. You should not ask 50 questions when they can't answer half of them, especially if they just want to tell you "You have a typo in decode.c" or even just say hi.
Time to enrollment. How easy is it to become a contributor? When I file an issue on your project, I am doing you a favour - you should help me help you. I have myself given up on several large scale projects because they use shit software for bug tracking. It's not fun.
A lot of people don't understand this today. Github has fixed these issues and this is a huge reason why they are popular. And before you say anything, this document here is about is not time to enrollment, but quality of life when you are already a developer (especially on large projects). I'd certainly love for GH to fix those.
Debian, in a similar vein, doesn't even have a web form to report bugs. As a result, almost every bug I've gotten on a Debian package has been clueful. At the very least, I know what version of the software they're running.
I've managed repositories that have gotten hundreds of low-quality issues. The poor filtering and curation functionality of GitHub ensures that a good deal of my spare time I have to work on those projects is spent managing the inbound issue flow, which is at least 90% noise.
The only reason one would use Github is for network effect.
Personaly i believe the ethical trade off to be too great, and I believe FOSS supporters should agree with me.
Also from a ethical point of view it's wrong to trust for profit commercial closed source for community driven open source work. I am sure history will repeat and github.com will become future sourceforge.net.
"I am sure github.com will take ages to do such thing" I have no idea what you're on about. I handled the migration of a massive bugzilla database to Github. Wrote this in the process. The github team was super friendly and helpful in assisting me in the process with zero delays (shout out to Ivan!).
Because, honestly, trac just sucks. It ain't as bad as the stuff Atlassian sells but still... it tries to be a fusion of MediaWiki and Bugzilla, and eh nope.
git issues "This needs attention"
>> Issue #1 created
>> List of issues
git issues -u #11
>> Issue #11 up voted
>> #11 Important stuff, needs attention
git issues -d #6
>> Issue #6 down voted
git issues -f #4
>> Issue #4 flagged
Maybe putting most of their efforts into Atom and Electron?
If GitHub is kicking back and sitting on their huge valuations, then it's time to pick up this work again. If issue tracking and code reviews were based on a common, distributed system like git itself, then all these companies could compete evenly for features and UX on top of such a system, without ever having the advantage of "locking in" its users with extremely high migration costs.
There is no longer an "if". It's absolutely true that GitHub is cruising at this time. For example: They are more interested in hiring community managers / community "heroes" instead of actual engineers in SF.
There you go: https://github.com/google/git-appraise
Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html
Amount of times I've posted a bug on a mailing list and a core developer doesn't care to respond is unbelievable. Here is a recent one:
Distributed is the key word. Blockchain/Bitcoin (not withstanding the hurtful politics ongoing at present) has shown the way, and ideally most shared/social things should work in a distributed, trust-less environment in future. Including Social networks and Search Engines.
So it is quite natural, that OSS developers can pave the way for shared/distributed source control (a protocol on top of GIT. Just like HTTP is over TCP).
Just to clarify, I don't hate github. But it sort of obscures the beauty/advancement that is GIT, over previous version control softwares. Wonder what does the creator Linus think of this?
Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.
Thinking about it, something like this would be sweet. I would immediately have a snap shot of things that might go boom when I run said software. eta: Instead, I have to go dig through github itself, which is slow compared to greping through a git log.
I'm talking about a portable issue tracker format that ideally uses something like git as its transport (but note: this does not mean that the issue database would travel along with the application's source code! That might be nice as an option but not by design). command-line and web-based front ends can then refer to it. Fossil, OTOH, looks like a huge monolithic web application / version control system / issue tracker / kitchen sink written in very hard-coded C.
Looking through some docs, Fossil is anti-git and it claims its own DVCS is a great improvement over git: http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki. Because Fossil has every possible feature packed all into one monolithic executable, rather than relying upon existing systems like diff, patch, etc. this means Fossil is "the opposite of bloat": http://fossil-scm.org/index.html/doc/trunk/www/qandc.wiki (in fact that is the opposite of the opposite of bloat....)
You would have to sign off every message in a git log tree with a personally authenticated gpg key that can be found in a public keyserver everyone trusts.
Distributed issue tracking would use a similar pull model, but in reality wouldn't normally need people to be "cloning" it or anything like that; more realistically, a project would have just one place that is the "official" bug tracker just like they do a git repo now. But with "distributed", you can now have read-only mirrors of it elsewhere, you can have alternative GUIs that can push to the "official" repo as long as you have an account on that "official" host (which may as well be github), etc. It's not as important that it's truly "distributed", more that this is a set of issues that as a body of information about a project can and does live in many places, just like the version control does, just like the mailing list does, just like the IRC logs do. Right now issue tracking is like none of these other things.
There’s not necessarily an antagonism between distributed and centralised in this case. You can still have a centralised frontend such as Github Issues, backed by a versioned and distributed backend using i.e. git.
How about improving Gittorrent?
Interesting side note: With the exception of Selenium, most of signees are maintainers of JS/HTML OSS projects. I wonder if we could objectively compare JS to <lang> projects in terms of the problems mentioned in the document. For example, there is a strong correlation between +1'ers and JS repos vs. Python or vice versa. Perhaps, we could walk away with JS devs are more chatty than CPP developers when discussing issues... I don't know, just a thought.
Monkey see - monkey do.
Is it really possible that people just continue standing there while not getting why they are doing it? Don't they even care to ask?
Feels like it would take just a single guy to ask: "What are we looking at?" For everyone to realize that they are acting like fools.
Try the classic: enter an elevator and turn around to face the back - see how many copy you.
1. Close the PR with little or no comment. People then think I'm an asshole.
2. Spend hours explaining why the code is terrible and why it can't be improved. In addition to being a big time sink, PR submitters often don't understand the criticisms. Half the time, they still think I'm wrong.
People even defend stuff as obviously wrong as adding a thousand lines of GPL'd code to an Apache-licensed project. Then they say I should remove .gitignore support from ag because it doesn't implement 100% of .gitignore syntax. As if users would be happier with tons of extraneous results instead of some extraneous results.
A lot of this is cultural, but GitHub could help steer things in a better direction with the features proposed in this letter. I hope they take this letter seriously.
2. User accuses ag of hard-locking his computer: https://github.com/ggreer/the_silver_searcher/issues/791
3. User wants ag to always print filenames, unlike every other tool out there: https://github.com/ggreer/the_silver_searcher/issues/749
4. User wants ag to replace PCRE with a totally different, incompatible regex library: https://github.com/ggreer/the_silver_searcher/issues/698
5. User aliases 'ag' to 'grep', then complains ag doesn't work: https://github.com/ggreer/the_silver_searcher/issues/578
To the person raising the issue it's a simple mistake, sorry.
To the person that has to deal with it, it's yet another issue being raised where the reporter didn't follow the necessary steps to diagnose the problem themselves and (implicitly) expected a bunch of other people to apply their own time to solving it.
If the "New Issue" form had a place where the reporter was asked to paste the output from ag --version then it might have caught the accident before it wasted the developers' time.
I think it's an over reaction to describe the issue as a complaint, but it is an example of how the GitHub UI forces project admins to deal with incomplete and poorly investigated issues from users.
Have I done dumb things without realizing? Of course. But in almost 20 years of software development, I have never created issues resembling the ones I linked to. Bug reports are seen by hundreds of people and take up valuable developer time, so I make sure mine are useful.
To use an analogy: Say I'm giving a talk to an audience of a hundred people. I wouldn't do it extemporaneously, without slides, then walk away in the middle of Q&A. And if I did, I wouldn't call it a mistake. I'd call it being a terrible presenter. Yet that's what bad bug reports are like:
User (notifying hundreds of people): "It doesn't work."
Dev: "What version are you using? What error messages do you see? How are you running it?"
User: * crickets *
It's gotten bad enough that I wrote a short post on how to report bugs.
Such a vague report tells you all you need to know about whether it's going to be worth your time trying to work with the person who submitted it. Close it immediately as non-actionable.
I guess it depends on the project and its contribution guidelines.
I seriously doubt the pendulum will swing too far in the opposite direction. Right now, the majority of created issues are close to useless. If those people took five minutes of their own time to troubleshoot, it would save others hours.
You can sort something by stars, but it's bad etiquette there for a user to comment +1 rather than just star.
This becomes heavily apparent when someone posts an Android issue directly onto the Android subreddit. I suspect the same could happen with GitHub issues. When you see others posting "+1", then others follow the same practice.
But still, yeah, it would be fairly trivial to require posts to be more than +1, or to display a warning when anyone starts a post with :+1:
I wonder if those types of projects are more likely to have these problems (larger userbase? Less experienced userbase? just different userbase?)? It could also just be a coincidence that they knew each other because they work on similar things, and a group of people who knew each other are the ones who wrote the letter.
Spam would indicate that +1 adds no value.. But it does! If I have an issue with no comments, no indication of its importance to the users, then I would deprioritize that issue over another one that has lots of activity.
>Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.
Every checkbox, text-field and dropdown you add to a page adds cognitive overhead to the process and GitHub has historically taken a pretty solid stance against this.
From "How GitHub uses GitHub to Build GitHub": http://i.imgur.com/1yJx8CG.png
There are tools like Jira and Bugzilla for people who prefer this style of issue management. I hope GitHub resists the temptation to add whatever people ask of them.
Yes! The maintainers deliberately want to add cognitive overhead so the quality bar for creating issues is higher.
By having simple zero-friction forms, you haven't removed cognitive overhead. You've simply shifted the cognitive load into the followup messages asking for clarification of "reproduction steps", "version tested". The issues' threads therefore begin with "meta" type questions which duplicate the checkboxes and dropdowns you were trying to avoid.
The default can remain zero-friction but it seems very reasonable to offer options for maintainers to gain some control over their inbox.
That's a reasonable answer -- but it's an answer to question I wasn't addressing. Whether github reinvents the wheel is not relevant to my point.
I was specifically debunking the illusion that "simplicity of the issues submission form == no cognitive overhead".
If the "issues creation" web form is lightweight, the submitters will eventually expend "cognitive overhead" by clogging up the threads with clarification messages.
If the project maintainer uses your solution of an external tracker, that means the submitter still expends cognitive overhead by noticing that the project's "issue tracking" has been disabled, and then reading front page README.TXT or CONTRIBUTIONS.TXT to figure out what external website he's supposed to use to submit issues. No doubt the web forms on those external trackers will have the checkboxes and dropdowns that some people are suggesting people avoid.
The "cognitive overhead" required to clarify and provide meta-descriptions for bug reports is inescapable. You're only deciding whether it is structured or unstructured and where it is shifted.
Your reply is going in different direction from cognitive overhead and on that perspective, I don't know what makes the most sense. My guess is that many open source maintainers don't need a heavyweight tracker that can do things like assign tasks to multiple programmers, burn down dashboards, correlate activity hours to billing, etc. They don't need all that. They just want a template to improve how users file issues. Maybe a survey would provide insight as to whether your answer is the most sensible.
And how many teams spend the first three months of a project building a custom issue tracker because they don't like any of the off-the-shelf options? Trying to get issue-tracking "right" is a black hole for a company like github. Which is probably why they provide the bare minimum free-form issue and that's it.
A simple optional field to include the version number that the issue was being reported against would do wonders for my interaction with users.
And you don't need to include that on your software project, but really if our users can't be bothered to tell us what version they're running, I have many, many other issues to fix which I know are broken in master.
Which I guess is the difference. If you're a small project with few users, then the handful of bug reports you get are useful and you want a zero barrier.
I have literally thousands of bug reports, hundreds of those will be left without ever being fixed (even though they may be perfectly legitimate). I have to triage. If a user is blocked by not being able to tell me what version they are running then that pre-triage of making them not even bother to cut a ticket with bad information is useful because then they don't waste any of my time...
As someone who has opened issues myself on projects in gitHub its easy to be unaware or even forget all the information a maintainer would need to reproduce the issue. As someone who uses an open source stack every day anything to make the whole issue flow better for maintainers and users I'm for 110%
- GitHub doesn't use GitHub issues to take feature requests or bug reports.
- GitHub doesn't use Pull Requests to allow users to submit bug fixes
When all your issues and pull-request are being raised by a defined set of people who are (or ought to be) committed to the same collective goal (because they're employees of the same company) you can develop a culture and norms around how those things work.
If "Some Guy" at GitHub raises issues where the only description is "This feature doesn't work on Mac" or raises PRs where the only description is "this fixes a bug I found" the cultural pressure would teach him/her that's not how things are done, and if the lesson wasn't learned, then they wouldn't last at GitHub.
When the people you're interacting with are infrequent contributors, it's a different scenario. They need guidance. They need to be pushed to go down the helpful path on their first attempt, because there are too many new contributors and they often don't stick around for long enough to change behaviours by osmosis and cultural pressure.
I do concur, but there should be at least some of them. One shouldn't have to hope that people will be kind enough to submit proper issues, the platform should force them somehow to do so. I think, if a study of github issues was made, we'd see that about first five messages on a given issue would be those of maintainers craving for more input. What is the output of dmesg, how is your configuration, what is the output of the process, can you run it with the verbose flag on... A bit of cognitive overload is good, so that who submit bugs are those who take the burden of doing so.
And I agree, simple is good... but simple is also bad for large projects, as while it makes it easier to create a ticket, it makes it harder to track for the maintainers. They are (rightfully) looking to ease their work, and I do believe it is a net win for both sides if filing a bug is made a little harder, but it becomes a lot easier to manage.
Taken all together, it seems like github is on a path of alienating their most valuable members. Github was unresponsive to Linus' feature requests and it turns out that theme continues almost 3 years later.
If github plans to evolve into a full-featured ALM like MS Team Foundation or JIRA instead of being relegated to being just a "dumb" disk backup node for repositories, they have to get these UI workflow issues fixed.
If github evolves to the projects you're mentioning, you'll surely alienate the many more casual users. I personally hate working with the bloated applications you mention.
Ummm ... anybody getting the irony here?
And, from a GitHub business perspective, why do I hear Lily Tomlin: "We don't care. We don't have to."
Everybody anointed GitHub as "the chosen one" over strenuous objections from some of us that creating another monopoly for open source projects is a bad idea.
Pardon me for enjoying some Schadenfreude now that GitHub leveraged the open-source adoption into corporate contracts and now doesn't have to give two shits about open source folks.
Lily Tomlin's Phone Company Sketch:
It's likely that GitHub will alleviate these pain points in time, but the lesson is the same: let a company control your destiny and you can no longer have what you want or need when their interests diverge from yours, even if their system is the best there is and was radically better than everything else at the time you switched to it.
Only gripe is that some parts of it are still highly coupled, so doing something like adding a custom button to the text editor view or writing your own internal application very quickly becomes a huge mess, an effect that is multiplied by the active development and no promise of stable public APIs.
Your experience will be great as long as you don't try and do anything custom, at least for the next year or two.
Seriously: if you have a web server (or php hosting) anywhere, try out phabricator; it's easy to setup, and you can even point it at a github (or any public git/svn/hg) repository to fiddle around with its features, as hosting the repository inside phabricator is not mandatory.
Making an issue or a pull request feels like having a casual chat with the project maintainers. Adding fields and other hoops to jump through puts distance between people.