Dear GitHub(github.com)
github.com
Dear GitHub
https://github.com/dear-github/dear-github
485 comments
An open question is how the community should provide feedback. Trello provides a decent example of how to do it well [1], but GitHub feels like a black box. I've been on GitHub since 2008 and I have been paying every month for years, but other than emailing support I have no idea how to vote for a feature request.
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 [2], but we have no idea how to get that on GitHub's roadmap.
[1] http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144
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 [2], but we have no idea how to get that on GitHub's roadmap.
[1] http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144
An open question is how the community should provide feedback.
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.
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.
Yes it is fairly bizarre that Github don't dogfood the issues function. I'm sure they have an internal system that they prefer, but even that internal system could have a public interface. Also, if the internal system is superior then its superior features could be added to the public system so that we could all benefit.
Where are you getting that they don't dogfood the issue tracker? It's a private tracker (private repository) but from what I've seen in the Github blog, they do... it wouldn't make much sense if they didn't.
If they're using it, they're doing so in completely different fashion than everyone else. That is, it's not public for viewing, submitting, commenting, etc. Indeed TFA indicates exactly the sorts of pain points that would be missed by those using the tool in such a radically different way than everyone else. If someone at GH had to wade through all the damn +1's then something would have been done about them years ago.
95% of all my github activity is in private repositories.
Ditto. Maybe 98%. I think that's a big part of the disconnect I'm seeing here in the comments. Those of us that live in private repos are likely pretty happy with how things currently work especially since we're the ones paying to use the service. If it wasn't working well for our teams, we'd find somewhere else to spend our money. That being said, we're certainly the minority when it comes to users on the platform.
I guarantee everyone maintaining a large public project on github has private repos and is paying for the service.
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.
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.
> 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.
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.
>That being said, we're certainly the minority when it comes to users on the platform.
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.
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 have the diamond level plan from GitHub and have >260 private repos at my company.
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.
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.
That's not how it works. Happy consumers leads to happy enterprise users. They are one and the same.
I only pay Github money to host my private repos because their platform also hosts most of the open source projects I use. If enough of those projects leave for a service that does open source better, I'll be happy to follow them. Otherwise I may as well be using Bitbucket or Gitlab.
We don't pay GitHub precisely because they lack features we can implement in GitLab.
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.
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.
GitHub pretty please, give us an option to hide our profile from search engines just like Facebook do.
What is the use-case of this?
I have an account that is only for private repos and I don't want that account to appear on search engines for my real name.
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.
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.
Just curious, why not have just a single account?
Your private repo's and contributions are not made public, so there's no "risk" involved.
Your private repo's and contributions are not made public, so there's no "risk" involved.
I think a lot of companies forced this because for a while the api permissions weren't granular enough when dealing with private repos on organizations. They added the "Third-party application access policy" sometime in the last year or two. I might be wrong though.
Do you feel like your usage is typical?
I would guess that private repos have a much smaller user base, in that that they work for companies where they are trained in specific policies to submit issues and work with the repos. With public repos you're at the mercy of widely differing levels of user experience.
> If they're using it, they're doing so in completely different fashion than everyone else. That is, it's not public for viewing, submitting, commenting, etc
Huh? Github isn't opened sourced so how is a different fashion from anyone else using private repos?
Huh? Github isn't opened sourced so how is a different fashion from anyone else using private repos?
Plenty of private projects use a separate, public Github repository for community reporting of issues, and public tracking of those issues.
But then they'd be spammed with useless +1 comments
+1
If one implemented issue voting then a +1 comment could automatically be converted into a vote.
Which is almost exactly what happens on GitLab: https://twitter.com/gitlab/status/687930087057027073
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.
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.
> My personal pet peeve is not being able to mark a public repo as 'deprecated'.
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)
https://github.com/coreh-deprecated
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)
https://github.com/coreh-deprecated
I normally put a big "[DEPRECATED]" notice at the beginning of the README. This normally doesn't go unnoticed.
Another good example is harthur's "[UNMAINTAINED]" [1]
[1] https://github.com/harthur/brain
Another good example is harthur's "[UNMAINTAINED]" [1]
[1] https://github.com/harthur/brain
I watch the project and did not see "UNMAINTAINED", cause i scroll automatically on github projects down to the readme.
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.
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.
Have a look at the trending erlang repositories[0]. You will always find, near the top, basho/rebar. However, the subject on this reads:
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. [0]https://github.com/trending?l=erlang
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. [0]https://github.com/trending?l=erlang
> I normally put a big "[DEPRECATED]" notice at the beginning of the README.
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?".
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?".
One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.
> One concern would be around tools that fetch from github automatically.
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]
I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?
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]
I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?
Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches https://example.org/pkg/foo?go-get=1. So coordination between go and github could implement something for deprecated repositories without changing anything in git.
More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths
More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths
> Go get does not start with a git clone.
Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) [0]
> ...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. :)
[0] Thanks for the documentation link, BTW! :D
Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) [0]
> ...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. :)
[0] Thanks for the documentation link, BTW! :D
I am not your grand parent poster but I fully agree with you and I'd go further than that.
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.
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.
> Github ought to be a hub.
So, I heartily agree that vendor lock-in is bad. [0] 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?
[0] I'm STILL mad about how Hangouts turned out.
So, I heartily agree that vendor lock-in is bad. [0] 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?
[0] I'm STILL mad about how Hangouts turned out.
At the very least, we could try to create standard conventions for vendors like github to adopt
Agree. I've had literary thousands of libs/tools/apps dependencies in one of my projects that was built using automatic tools (Bitbake + Yocto). It's simply impractical to go through all these README's manually, so a tool to detect depreciated projects is a must in such situations. Of course, one could implement some tool to scan all README files for keywords ('DEPRECIATED', 'UNMAINTAINABLE' etc.), but that's just a workaround and I'd like a proper, reliable way to do that.
What if the maintainer never marks the library as deprecated? What if they're just hit by a bus?
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.
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.
"What if the maintainer never marks the library as deprecated? What if they're just hit by a bus?"
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.
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.
My primary use case would be searching projects and filtering out deprecated ones.
Someone came up with http://unmaintained.tech/ for exactly this reason. You can add a badge to your README.
I've had pretty good success with feature requests in Github – but I agree that it at least _feels_ like it depends on who is replying to you (or even what state of mind they're in; copy paste responses has been had).
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.
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.
As a software engineer, I am reminded of when I go to Home Depot and ask someone for help and they say, "Oh, I do not know. I am new here...". I think it is best to come prepared with the right answers. As you can see from the doc, there are a lot of maintainers who have signed this. Perhaps:
- 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.
- 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.
My main goal in responding was to acknowledge the issues. This is just the start of the process, and by no means the end.
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.
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.
I'm glad to see someone from github is actually replying on HN and not ignoring this. Thumbs up
Not just anyone - Jono literally wrote the book on building developer communities: http://www.artofcommunityonline.org/
It is also freely available as PDF - http://artofcommunityonline.org/Art_of_Community_Second_Edit...
He also founded and hosted a fantastic Linux podcast a long time ago: http://www.lugradio.org/
You are far too kind. Thanks!
You did the right thing, fast feedback of "We are looking at it" is often better than later feedback of we did "X".
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.
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.
It's much better for Jono to quickly reply and ack the issue, rather than radio silence while we want for them to completly solve the issue.
I personally prefer someone to at least acknowledge someone now owns the issues than to wait in silence while they gather the right people and formulate a concrete response. That doesn't happen quickly in some cases and the silence can exacerbate the issue, which ironically is why this hit HN in the first place.
I appreciate the prompt response. Face-to-face at Home Depot you know the message was received. Online it's nice to get an immediate read receipt with the real reply coming later.
Promises about the future about Github’s roadmap is understandably difficult to make, besides by a very small number of people at the top. I don’t think this is the expectation. But visibility into past failure to address these concerns and the current status is long overdue. I assume when these maintainers reached out in private channels, they were equally detailed, and have waited years.
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.
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.
GitHub has settings for individual repos. People can opt to turn the issue tracker off completely.
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.
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.
You can't fully disable the issue tracker: Pull requests can't be disabled and each PR becomes an issue.
One thing I would love to see for my own projects is a way to temporarily completely block off contributions on threads by people who only watched/starred the repository for less than 48 hours or something like this.
When people submit your issue tracker to hackernews/reddit/twitter all hell breaks lose and time gets wasted for nothing.
When people submit your issue tracker to hackernews/reddit/twitter all hell breaks lose and time gets wasted for nothing.
Interesting idea, but I wonder what the right metric is to determine legacy vs. new users. I certainly haven't starred/watched every package I've ever `npm install`ed.
Respectfully Jono, I think your reply is symptomatic of the issues at the heart of the matter. GitHub is, whether it expected to be or not, whether it wants to be or not, now at the heart of the OSS community. For the "Director of Community" at a company which plays such an important role in the OSS community, which itself plays an enormously important role in the broader software and civic communities and is populated by abnormally high numbers of passionate and talented contributors, to respond to a HN story with such a high profile by:
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.
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.
Your response, specifically #3, makes me wonder if you have ever worked in a medium to large business. Forgive me if I read it wrong. I think his response is solid and the best that one could expect from his role. I could not imagine some director from a different department by passing the product team and coming to my development team and saying, "stop what you are doing, and handle my request! I read something on HN! I need a plan of action that directly addresses issues that were raised!". I would, however, expect him to say that he knows or can find out (he is new still) who needs to see this and make sure the discussions happen to ensure that product team has the information required to make an informed discission allowing for a roadmap to be formed that could be shared with the community. He can totally guarantee the right people see it. He can't ensure they do anything about it, but he can champion the issue. I would hope/expect to hear back after all this has happened. What's wrong with saying he is still getting an understanding of how things work at github? And what approval are you dismayed with? His acknowledgment that feedback is important? That was just civility.
I have indeed worked at a very large (both capitalization and payroll wise) company. I've also worked at small and medium sized companies. But, as relates to my experience at the very large one, this guy would have been eaten alive for putting out that response. Perhaps your definition of large is different from mine. However, my point had nothing to do with the size of the company and everything to do with the role the company plays within the OSS movement.
At least he responded, and promptly. Let's not jump to conclusions just yet.
One suggestion is to improve the permissions system. For example, third-party github plugins that interact with the github system (e.g., setting labels, responding to comments) require "write permissions" which gives those systems "push" access to the underlying repo. Simply separating the git repository access control from the github UI / issues / pull requests access control system would be very helpful. I'm sure there are many other examples of where the permissions system needs some finer-grained access.
Edit: Essentially the same as reported here: https://github.com/isaacs/github/issues/268
Edit: Essentially the same as reported here: https://github.com/isaacs/github/issues/268
Perhaps Github Issues itself should be available as a mechanism for people to provide feedback about Github itself.
Hypothetical link: github.com/github/github/issues
I've been personally paying for a couple of years, and the SAAS company I work for (~50 engineers) has committed to moving away from Github for some of these (and other) reasons.
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:
* https://github.com/isaacs/github/issues/18
* https://github.com/isaacs/github/issues/215
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:
https://twitter.com/Ash_Coolman/status/670595632659206146
But instead I got nothing, except a vague sense of having offended someone (sorry BTW, it was only a joke! :'()
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:
* https://github.com/isaacs/github/issues/18
* https://github.com/isaacs/github/issues/215
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:
https://twitter.com/Ash_Coolman/status/670595632659206146
But instead I got nothing, except a vague sense of having offended someone (sorry BTW, it was only a joke! :'()
I've witnessed Jono's outstanding work at Canonical/Ubuntu, and as you can see from his comment above he's a great guy. No matter what you think of Github, I think you should appreciate this.
There appears to be a need for some a different class of repository for larger open source software.
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.
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 you THE Jono Bacon of Ubuntu fame? If so, I have the best of hopes for Github.
Best of luck in your new position and I hope we'll get to see many great new features on the platform.
There are more authors on the second page.
That's why you shouldn't use Google Docs for such an article (even if it comes in the form of a letter). Nobody expects the concept of pages on the web (as in books, not as in web page).
Comments like these baffle me and I have to wonder
* 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.
* 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.
Did you....not read the open letter? Or not realize that the scrollbar for this one goes all the way to the end of the page, and then there's an inline link saying 'see more signatures'?
When I read the letter, I saw that it extended across two printed pages. Were these printed pages not the pages to which pvorb was referring to?
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))
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))
Yep, I've been looking at the Google doc. Basically I think it's just a bad way of publishing things online.
Often browsers don't show a scroll bar at all like on my phone, if you're not actively scrolling.
And yes, most of the time "we" are in such a hurry. At least I am most of the time. Time is limited.
And yes, most of the time "we" are in such a hurry. At least I am most of the time. Time is limited.
Oops: I posted too quickly. Updated.
[deleted]
Not sure you'll read this but I'd love a tagging feature for starring. Sorting on code isn't good enough.
Nice to meet you Jono. I maintain a similar list, albeit a bit more focused on GHE. https://github.com/kevinSuttle/github/issues
@jono Will you be able to answer, if github has any plans in the roadmap to open source the code in 1-2 years and develop in open instead of closed rooms.
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.
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.
Problem with them open sourcing their platform is that the platform base is used in enterprise and how the bulk of their revenue is made... Who wants to buy milk when the cow is being given away?
They are getting hosting deals for many of these companies themselves. Why spin up your own github clone when you can just use github?
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.
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.
This, I feel, is the most important bug, even though it precedes the list:
> 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[1] 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?"[2]. Many of the issues that have been filed there are excellent ideas.
[1]: https://github.com/isaacs/github
[2]: 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.
> 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[1] 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?"[2]. Many of the issues that have been filed there are excellent ideas.
[1]: https://github.com/isaacs/github
[2]: 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.
The author mentions that if GitHub was open source, they would implement these features themselves.
Gitlab[1] 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.
[1] https://gitlab.com/gitlab-org/gitlab-ce/tree/master
Gitlab[1] 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.
[1] https://gitlab.com/gitlab-org/gitlab-ce/tree/master
This. When you are tired of github, start using gitlab, and realize your mistake going forward and stop making it, over[1], and over[2], and over[3].
[1] http://sourceforge.net/
[2] https://code.google.com/
[3] https://bitbucket.org/
[1] http://sourceforge.net/
[2] https://code.google.com/
[3] https://bitbucket.org/
Sourceforge runs Apache Allura, which is open source.
What's realistic timing for getting a feature you contribute (and receive approval) deployed and available for use?
The length of the merge request cycle depends on the complexity of the feature. Simple fixes get merged in days, average features take weeks and sometimes the review suggestions take multiple months to implement. After merge it will release in weeks so since we're on a monthly rel cycle.
At GitLab we would welcome contributions. More than 1000 people already contributed and everyone is welcome. Also see my other answer in this thread https://news.ycombinator.com/item?id=10905756
Absolutely agree!
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.
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.
gitlab.com is dog slow and my code is too important to risk self hosting.
GitLab.com indeed is dog slow, we're sorry and we're working on improving that Q1 2016 https://gitlab.com/gitlab-com/operations/issues
So happy to see you acknowledge the performance issues. You'd do everyone a great favor when you make it happen!
Wait, are you telling me that every git repository isn't a full copy of the codebase that you could recover from?
Really? I find that hard to believe, but it makes me glad I use Mercurial if that's the case.
Really? I find that hard to believe, but it makes me glad I use Mercurial if that's the case.
Git repositories do have a full copy of the codebase (unless using some large-file management, same issue with largefiles extension for hg).
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
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
So host on multiple sites?
Deploy on Heroku
Installing it on Heroku is not an option because their containers do not allow the disk access GitLab needs to store and manage the git repo's. source: https://www.quora.com/How-much-of-a-threat-is-GitLab-to-GitH...
Alrigh, sorry. I didn't know.
This was my first thought after reading it. I've used gitlab.com, also locally, and it is ok. Presumably people will want to stick with github due to popularity though.
It's 2016, and GitHub is stagnant.
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.
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.
> 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.
https://twitter.com/agelender
https://twitter.com/_danilo
https://twitter.com/rachelmyers
https://twitter.com/nmsanchez
https://twitter.com/BiancaCreating
https://twitter.com/ammeep
https://twitter.com/davystevenson
Maybe something more noble than a social coding site?
I've been puzzled for a while with what github is doing hiring so many social impact employees.
https://twitter.com/agelender
https://twitter.com/_danilo
https://twitter.com/rachelmyers
https://twitter.com/nmsanchez
https://twitter.com/BiancaCreating
https://twitter.com/ammeep
https://twitter.com/davystevenson
Maybe something more noble than a social coding site?
Maybe something more noble than a social coding site?
Even if you don't have anything against Github relating to the Horvath incident, there are other things like Github shutting down people's projects because they wrote a doc containing the word "retard." In other words, now they are in the business of regulating the content of open source projects (beyond obvious precautions like not hosting stolen credit card databases, child porn, etc.)
They seem to think they're too big to fail.
They seem to think they're too big to fail.
They also removed [0] C Plus Equality [1] project twice. Even Bitbucket [2] and Google [3] also removed it.
[0] - https://github.com/FeministSoftwareFoundation/C-plus-Equalit...
[1] - https://github.com/ErisBlastar/cplusequality
[2] - https://bitbucket.org/FeministSoftwareFoundation/c-plus-equa...
[3] - https://code.google.com/p/c-plus-equality/
[0] - https://github.com/FeministSoftwareFoundation/C-plus-Equalit...
[1] - https://github.com/ErisBlastar/cplusequality
[2] - https://bitbucket.org/FeministSoftwareFoundation/c-plus-equa...
[3] - https://code.google.com/p/c-plus-equality/
What was the story behind this anyway? I am having a hard time determining whether this was actually serious or were trying to parody feminist activism.
Good.
> now they are in the business of regulating the content of open source projects
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.
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.
And who exactly gets to decide what is "fringe"?
[deleted]
I guess that the majority gets to decide. It doesn't really matter what is mainstream and what isn't, as long as there's a place for both. Broadway and off-Broadway are both fine, but mixing them can cause confusion and for both audiences to be disappointed.
Ah, majority rules. Which is an excellent system, as long as you are in the majority. Hopefully the majority doesn't decide to remove what is not their agreeable mainstream.
I didn't say that the majority rules, just that the majority defines what is mainstream. If you want to run an open-source project that promotes misogynistic values, be our guest -- just don't do it on GitHub.
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).
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).
>> I didn't say that the majority rules, just that the majority defines what is mainstream.
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.
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.
> The problem is one group feeling they have the power to dictate to the "other".
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.
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 sorry, but I still see examples that only explain what majority rules is. I'm not seeing where you are suggesting one thing or another different than what I've said. Again, it's an excellent system as long as you agree with the majority.
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.
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.
Unfortunately, we've seen a lot of situations where the "majority," at least of those who speak up, are (for example) opposed to heavily restrictive codes of conduct proposed by outside groups, yet the code is forced through anyway by project leaders. Majority rule seems to be valid only when the majority votes the "right" way.
OK, but do you have a better system? The large, mainstream platforms need to be managed somehow, and their content has to be not too far from the consensus. You don't have to like it, but that's how the mainstream operates. As long as you have other venues where you can do stuff that's outside the consensus, I don't see the problem. I think that the way GitHub is managed now in terms of content (including code of conduct enforced by project leads) is very reasonable for a mainstream platform.
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.
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.
Oh, I agree with you as far as majority rules. It's not great, but you need something and that's less unjust than most other options. What I'm complaining (pointlessly) about is that in these cases majority does not rule: some administrator or corporate functionary has already decided, and that's that.
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.
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.
> Not if the "experts" do everything in their power to marginalize and poison the public image of those non-mainstream platforms, unfortunately.
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.
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.
I think you're missing the distinction between what is legal and what is right. I will cheerfully agree that the "expert" attempt to marginalize those who disagree with them politically is legal, and any attempt to legally prohibit it would have worse consequences (not least of which, the experts would use new laws as a weapon against their enemies rather than the other way around.) I will not, however, grant that it is right.
> 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.
> 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.
so what do you think of saudi prince becoming second twitter biggest stakeholder. He is free to censor anti saudi govt speech on twitter?
I don't know what you mean by "free". Of course, a business owner is free to direct their business as they wish within law. Would I like it? No. But businesses are rarely ideologically neutral, and they often reflect the ideals and world views of the societies that created them. As Twitter is a Western company, it reflects Western notions, so I wouldn't be happy when it starts reflecting Saudi world views, but if it does, I guess someone will start another Western Twitter. If you want Twitter to be a public infrastructure rather than a private business, make it a government-owned company.
It's the "etc" that allows you to remove "retard".
"Regulating content" just meaning having some standards for what is hosted on their sites.
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.
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 happen to be an acquaintance of Rachel Myers, and while she does do not-for-profit stuff outside of work, do you have some evidence that she's a "social impact employee" there? It's not obvious on her Twitter/Github profiles.
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".
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".
I assumed it had to do something with community involvement from here
https://github.com/blog/1521-rachel-myers-is-a-githubber
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
eg:
http://connecthome.hud.gov/
https://github.com/detroitwaterproject/detroit-water-project
I was merely curious about how this fits into their grander strategy.
https://github.com/blog/1521-rachel-myers-is-a-githubber
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
eg:
http://connecthome.hud.gov/
https://github.com/detroitwaterproject/detroit-water-project
I was merely curious about how this fits into their grander strategy.
[deleted]
[deleted]
Yeah, I'd honestly like for a website that actually focused on "Social Coding" rather than the Enterprise Money that GitHub is focusing on. Tbh, that is what GitLab, Bitbucket does also which is why they really are only effective as replacements rather than improvements upon.
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.
EDIT:
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 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.
EDIT:
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.
Recently even Python language planned to move its repositories to github.com for network effect, instead of helping projects like kallithea SCM and trac by partnering with software conservancy or gnu. Python should learn a lesson when they decided to move their repository to closed source system like github. But obviously as people use Facebook, developers use github for the same reason, network effect.
I hope they change the decision to support one of the project like Kallithea or trac by migrating their system and build network effects.
I hope they change the decision to support one of the project like Kallithea or trac by migrating their system and build network effects.
> instead of helping projects
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.
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.
Ubuntu has actively moved away from directing users to Launchpad to report a bug from a crash, and instead moved towards reporting to a crash database where they're triaged by actual developers.
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.
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.
Thank you for your time spent on Debian!
Gitlab is FOSS and does everything Github does (arguably) better.
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.
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.
Look at diagoproject.com's ticket triage. They moved repository to github.com but cannot move issues there. It's built on trac and works. I am sure github.com will take ages to do such thing. Indeed even Python needs to rely on roundup for issues tracking. Now the developers will be more miserable since issues won't directly link to commits or changes which is loss of integrity.
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.
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.
The django project is one of the last big trac users. That doesn't mean it's a good idea to use trac. They should definitely move issues to github, or at least to a better issue tracking platform.
"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[1] in the process. The github team was super friendly and helpful in assisting me in the process with zero delays (shout out to Ivan!).
[1] https://github.com/jleclanche/bugzilla-to-github/
"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[1] in the process. The github team was super friendly and helpful in assisting me in the process with zero delays (shout out to Ivan!).
[1] https://github.com/jleclanche/bugzilla-to-github/
> and trac
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.
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.
I still get a few emails a year from Trac instances where there is no support for unsubscribing emails
OMG can we get a moratorium on "tbh"? Just say "Indeed" or some other filler. "To be honest" is bad writing even when it's spelled out.
How reasonable is it to make issue tracking and social interaction part of the SCM itself [with optional web interface] ?
git issues "This needs attention"
>> Issue #1 created
git issues
>> 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
git issues "This needs attention"
>> Issue #1 created
git issues
>> 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
Your `.git` directory would become huge pretty quickly and you would have plenty of problems with people commenting on issues without having a repo up-to-date. How would you handle conflicts in that case?
How is that a different problem than people editing code in a repo that's out of date?
You have to be a coder to participate~
> They're chasing some other goal...whatever it is.
Maybe putting most of their efforts into Atom and Electron?
Maybe putting most of their efforts into Atom and Electron?
Mayhap it is related to their abandonment of being a meritocracy as doing such was being divisive? Success can be very devise as well so perhaps they are making a noble sacrifice to avoid dividing people.
We need world class, modern, distributed bug tracking now. If you google around for this technology, a lot of nice ideas, many using git itself as transport, were poking around, and around 2009 they started falling silent. Why? Because GitHub started up and everyone just buzzed over to it like so many moths to a flame, having learned nothing from places like Sourceforge about what happens when 90% of the open source world trusts their issue trackers, which is really a huge part of a project's documentation, to a for-profit, closed source platform that does not provide very good interoperability.
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.
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.
> If GitHub is kicking back and sitting on their huge valuations,
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 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.
Seems like this open letter is exactly the kind of thing a community manager should have gotten on tho.
This. I'm a big fan of Github, but it bothers me that this single service is the centerpiece of most OSS projects. We see it every time Github goes down and virtually nobody can be productive anymore.
I hope to see a version control system on top of IPFS some day.
Ironically, git itself is decentralized. More effort should go into decentralized software architectures, especially in the current security climate where having a central point of failure is like having a virtual bull's eye for bad guys. There's no reason you couldn't have a decentralized issue tracker for example.
> If issue tracking and code reviews were based on a common, distributed system like git itself
There you go: https://github.com/google/git-appraise
There you go: https://github.com/google/git-appraise
Suckless have discussed this several times and have fallen back to an email mailing list.
http://lists.suckless.org/dev/1201/index.html#msg10574
Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html
http://lists.suckless.org/dev/1201/index.html#msg10574
Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html
The problem with mailing lists is that patches and bug reports get forgotten.
Well that's a problem with the developers.
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: http://lists.alpinelinux.org/alpine-user/0042.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: http://lists.alpinelinux.org/alpine-user/0042.html
>We need world class, modern, distributed bug tracking now
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?
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?
Well, for one he doesn't like GitHub pull requests. ;)
https://github.com/torvalds/linux/pull/17#issuecomment-56546...
https://github.com/torvalds/linux/pull/17#issuecomment-56546...
> We need world class, modern, distributed bug tracking now.
Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.
Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.
I am not Michael Bayer (but I hope to be more like him someday)... that said, what I think he means or could mean is that issues would be distributed along with the repo. Maybe something like a git log for issues that are attached to and/or part of the repo itself.
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.
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.
You've described Fossil.
http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
yes, fossil, you need to get me past this:
http://fossil-scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...
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....)
http://fossil-scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...
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....)
Problem is for that system you need per-user authentication mechanisms to verify the interacting party in a bug report. If you can't do that, people can impersonate project members and you're going to have a bad time. Centralized issue tracking is not winning because of implementation details, its winning because you need some central authority to verify people are real and who they say they are.
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.
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.
All of those issues would apply to DVCS as well, I can clone any project and commit whatever crap I want to it, I just can't push to the main repo of the project.
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.
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.
Bugs Everywhere was one of the leading distributed bug trackers. They don't seem to be gaining any traction unfortunately.
http://www.bugseverywhere.org/
http://www.bugseverywhere.org/
Also, no GUI emerged. This is what github gives you on top of git.
Why distributed version control? You need a central place to pull from and push to, to ensure that forks and patches are not duplicated everywhere... ;)
[deleted]
I wrote a little bit about this two years ago: https://sny.no/2014/04/dbts
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.
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.
You mean like GitLab?
GitLab is still centralised (whomever is hosting…), not distributed.
Maybe you're interested in this feature request https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 to implement cross-server (federated) merge requests.
True.
How about improving Gittorrent?
How about improving Gittorrent?
I do not operate a popular OSS project, but I have experienced the +1 spam and it sucks. The suggestions, in my opinion seem rational.
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.
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.
I think it's just monkey see->monkey do. As soon as one person said +1, everyone that saw it thought that that's just how you voted for stuff. It's the same reason you see comments on HN or reddit that just say "This." or that if you leave your shoes by the door, everyone else will do the same. I doubt these people keep doing it if you ask them not to.
There's an old story about this man who stood quietly next to a closed door in Moscow, said nothing to no one, and did nothing else of interest. Eventually others joined him, and before long a queue has formed. No one knew what they were standing in line for.
Monkey see - monkey do.
Monkey see - monkey do.
I remember one day I was walking through london with multiple hours to kill; and there was a massive line. Without anything else to do, I just stood in it. Approx 45 minutes later, I got to the front: turns out it was a sale for a clothing store. I didn't really need any clothing, but the discounts were good; so I purchased a jacket. This was 6 years ago and it's still my favourite jacket....
One of Milgram's experiments (not the infamous one) tested this, using people standing on the sidewalk looking up.
https://youtu.be/P0e6zG8IbE8
https://youtu.be/P0e6zG8IbE8
I really want to try this out myself now.
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.
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.
So try it! Elevators are wonderful places for things like this :)
Try the classic: enter an elevator and turn around to face the back - see how many copy you.
Try the classic: enter an elevator and turn around to face the back - see how many copy you.
I agree that that's probably how it started, but it seems that once the cultural expectation has been set, it's hard for a single project maintainer to set a different custom just for their own project. People are going to use the conventions and communication methods that they learn elsewhere, even if you say not to in the contributing guidelines document. You might be able to get individuals to stop doing it in your project by asking them directly, but then each person has done it at least once, and you've had to ask each person to change their normal habits.
Besides, as they note in the letter, there is a valid and valuable purpose to these communications, it would just be better if they were in a different place than clogging up the comment thread.
StackOverflow tackled this by intercepting plus one posts and telling people to just vote. GitHub should do the same (with starring or following).
Yeah, and now look at SO, it's got so many "rules" that you can't look cross eyed at it without breaking one of them. "You don't have enough rep!" "A minimum of 15 characters per comment." "At least 5 characters per edit." "That's been asked before." Eventually, everyone just stands in line with blinders on, forced to stare straight ahead, mouth shut, one step at a time. There's never an end once you start "tackling" these so called problems.
"This." or "+1" is a more expressive way of showing support beyond anonymous voting mechanisms.
I maintain a C repo[1] and user idiocy is much lower than what I've seen in JS projects of similar popularity. Still, I agree with these criticisms of GitHub. I hate +1 spam enough to delete such comments. Sometimes I even ban those who do it. I'm frustrated by people who open idiotic issues[2][3][4][5]. I procrastinate on bad pull requests because my options are:
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.[6] 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.
1. https://github.com/ggreer/the_silver_searcher
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
6. https://github.com/ggreer/the_silver_searcher/pull/614
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.[6] 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.
1. https://github.com/ggreer/the_silver_searcher
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
6. https://github.com/ggreer/the_silver_searcher/pull/614
I actually hesitate to really "watch" repos because the sheer volume of email generated is staggering. I take my hat off to those who run successful OSS projects. Thank you!
About number 5. I don't see anyone complaining about anything.
Maybe "complain" is too strong, but he created a GitHub issue –notifying several hundred people– without running ag --version. Heck, he didn't even look at the output of his command. It was immediately obvious to me, from the limited information he provided, that it was a bash alias.
Looks like a genuine mistake. He apologised. You've never done something dumb and didn't realise it?
I think this gets to the root of the GH problem
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.
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.
All successful products will have stupid users. If you don't want to have stupid users, don't write successful software.
A mistake, I can understand. But each issue I linked to was not a mistake. Each one was the end result of a series of mistakes stemming from a combination of ignorance, negligence, and (occasionally) incompetence.
Have I done dumb things without realizing? Of course.[1] 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.[2]
1. https://news.ycombinator.com/item?id=7145451
2. http://geoff.greer.fm/2015/08/15/how-to-write-good-bug-repor...
Have I done dumb things without realizing? Of course.[1] 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.[2]
1. https://news.ycombinator.com/item?id=7145451
2. http://geoff.greer.fm/2015/08/15/how-to-write-good-bug-repor...
Why would you even respond to a bug report that was "it doesn't work."
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.
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.
As much as I respect you for The Silver Surfer, that 5th issue was a very silly mistake.
Do you really want people to be afraid to report an issue in case it's something silly/not an actual problem? Would that be better?
I guess it depends on the project and its contribution guidelines.
I guess it depends on the project and its contribution guidelines.
> Do you really want people to be afraid to report an issue in case it's something silly/not an actual problem? Would that be better?
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.
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.
True, but it's still user problems that aren't problems with the software itself. Far too often you get people who want help with _everything_ on a project, from installing the right language, their editor and so on when it's not something that really concerns you.
SourceForge fixed the +1 issue recently.
The same question about JS repos struck me. I suspect that if you write a shared letter then you just ask your network to sign it instead of <random other person from different ecosystem>, but I would be curious to know if these grievances are disproportionate in different communities.
I'd like to think that someone who writes this kind of letter would take such a thing into account. It's really possible that there is a strong correlation between a language and people being more involved with Github. I wouldn't be surprised that many developers from other language ecosystems just don't care.
Stack Overflow tried preventing +1/-1 comments[1], and the community came to the consensus[2][3] that those comments can be useful.
[1]https://meta.stackoverflow.com/questions/277314
[2]http://meta.stackoverflow.com/a/277319
[3]http://meta.stackoverflow.com/a/283935
[1]https://meta.stackoverflow.com/questions/277314
[2]http://meta.stackoverflow.com/a/277319
[3]http://meta.stackoverflow.com/a/283935
From skimming, they found "+/-1, because REASON" to be valuable, not "+/-1". Indeed, in the open letter, they mention these are valuable, but the current implementation is a pain.
Google Code has primarily been used for Chromium's issue tracker, but they have a star system for exactly this reason.
You can sort something by stars, but it's bad etiquette there for a user to comment +1 rather than just star.
You can sort something by stars, but it's bad etiquette there for a user to comment +1 rather than just star.
Yep. The problem is that some users are not aware of the conventions, and often you see on the Android Google Code repo "+1" or something along the lines of "Google plz fix this".
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.
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.
It seems to me that it would be a good idea to have a special-case that turns a comment where the only content is "+1" into a star request instead.
I believe GitHub translates :+1: into a thumbs-up icon, so you'd probably want to limit your filter so it only applies to non-contributors.
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:
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 agree that the suggestions are great; I'm also generally happy to see a letter like this take a clear tone without being aggressive or overtly confrontational. Re: the prevalence JS/HTML projects, I think that may just be a matter of simple base popularity; the web is the most popular development platform, and JS is the most used language on github (githut.info has great stats on this). If the letter gains steam, I'm sure we could expect project maintainers from other ecosystems to get on board.
I noticed that most of the signers are maintaning JS/HTML projects too.
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.
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.
+1 isn't spam. It's valuable. However the implementation of how people can +1 an issue that's very important to them is the point. There should be a voting system.
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.
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.
+1 is valuable, it's just the form that Github forces it into (comments) winds up looking spammy. Make it a counter - simple enough.
This first request is the anti-thesis of GitHub's simple approach:
>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"[1]: 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.
[1] http://zachholman.com/talk/how-github-uses-github-to-build-g...
>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"[1]: 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.
[1] http://zachholman.com/talk/how-github-uses-github-to-build-g...
> adds cognitive overhead to the process
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.
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.
So use a real issue tracker. Most of the big ones integrate with github. Why should they reinvent this wheel?
>So use a real issue tracker.
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[1] 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.
[1]https://www.google.com/search?q=jira+submit+issue&source=lnm...
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[1] 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.
[1]https://www.google.com/search?q=jira+submit+issue&source=lnm...
If not to be a hosted software lifecycle tool, what the hell is Github even for?
"Software lifecycle tool" is too vague for a product to have focus and open to too many interpretations as to what it should include. Even limiting scope to issue tracking, there are different points of view on how that should work and several widely-used but rather different software alternatives to choose from.
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.
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.
Zero structure just leads to lots of shitty issues that have no information on what version of the software it was against, no reproduction steps, and no stacktrace or debug output. I'm tired of closing issues with "I cant reproduce at all, maybe you're on an old version? Anyway feel free to open a new bug if you ever come up with a reproduction step..."
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...
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...
This is very true. While clunky to use most support sites for enterprise software includes these types of fields as mandatory to complete a support ticket.
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%
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%
But the big thing that GitHub doesn't use GitHub for is interacting with the masses.
- 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.
- 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.
> Every checkbox, text-field and dropdown you add to a page adds cognitive overhead to the process
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.
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.
If I read it right, they're not asking for a more complicated default for all projects, just that they can customize it for their projects.
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.
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.
It can be as simple as a text file that is dropped into the content-free TEXTAREA that currently greets new issue reporters. Try running a big project like jQuery, Angular, or Babel and you'll understand how important a feature like this would be.
Disagreed. In a free-for-all environment like FOSS, collective lack of details means more time wasted to gather/request for relevant information. Maintainers have the rights to request for such things before sifting through a potential mess of mostly incomplete issues/PRs. Their time is better spent anywhere but gathering correct versions to chase down a bug. People should have the common sense to provide those beforehand but alas, many do not.
It may take cognitive overhead away from the submitter but it shoves it onto the maintainet at the same time. Instead of 100 people having to deal with 1u of cognitive overhead each, you have 1 person having to deal with 100u or more to extract information from the submitters.
This is why your application should always have a "dump version string"-button, conveniently embedded together with your "report bug" button which doesn't have to be more advanced than simply opening your email-client or forward you to a webpage. This form should be free text but pre-filled with the version string pasted at the top and contain headers that invite the user to fill in the rest, such as Reproducing: <write what you did to cause the bug>. 100 different drop-downs makes nobody happy.
The bullet points of complaints feel like a continuation of Linus Torvald's refusal of github pull requests in May 2012.[1]
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[2] 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.
[1]https://github.com/torvalds/linux/pull/17#issuecomment-56546...
[2]https://en.wikipedia.org/wiki/Application_lifecycle_manageme...
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[2] 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.
[1]https://github.com/torvalds/linux/pull/17#issuecomment-56546...
[2]https://en.wikipedia.org/wiki/Application_lifecycle_manageme...
I don't see anything wrong with going after the massive amount of smaller project with simple needs, instead of the few large projects & popular projects with very specific needs.
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.
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.
Distributed revision control users whining about centralized repository lacking features.
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: https://www.youtube.com/watch?v=CHgUN_95UAw
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: https://www.youtube.com/watch?v=CHgUN_95UAw
I'm an open source project maintainer and share many of the pain points outlined in the document, but I also totally agree with you. Giving control of your project to a company means losing control and having to resort to desperate pleas like this. This is simply what happens when you can't fork it yourself like you could with an open source project.
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.
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.
There's been no mention of phabricator yet so I thought I'd give it a shout out. It's used by LLVM, FreeBSD, Blender, Wikimedia and others and I love it. It's under very active development and even if it doesn't solve every issue in this letter, by using an open source tool for development you of course have the option to customize it to the needs of your community.
[deleted]
I'm looking very closely at Phabricator, it looks quite nice.
Phabricator is pretty great overall, love that it's under such active development.
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.
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.
Phabricator is great! I host it for a couple of my projects. I love it, and it was easy to setup.
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.
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.
Another shoutout here to phabricator. I started hosting it internally at the company a year ago and have near 100% adoption from developers for code reviews, additionally using the task/issue tracking for some projects.
Thanks for the suggestion, I didn't knew about it. After a quick read, it seems to be a very interesting alternative.
Is this a case of the squeakiest wheels getting the grease? What if these problems aren't representative of the overall user base? What if far more people prefer a more simple, minimalistic interface than an ultra-customizeable interface with myriad custom actions and events. I've always appreciated software that deliberately keeps things simple (Basecamp and Workflowly come to mind). It sounds like these people want a full blown Jira/Stash installation.
I don't like the general feel of these suggestions. It sounds like more bureaucratic features, the lack of which is a big part of why GitHub is so pleasant.
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.
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.
I guess for maintainers of popular projects, everybody's "casual chat" (by people who did not read CONTRIBUTING.txt, do not supply the version of relevant software they are using etc.) is not as fun as it is for you.
Wow, what a bunch of whiners. If you hate github so much why don't you just fork it and fix-- Oh, right. It's not open source.
Well, there's your problem right there.
(I have sooooo much more in this vein but I'll spare you. ;-)
EDIT: No I won't. Fuck it. This is too ridiculous.
These guys (and they are all guys) chained themselves to github's metaphorical car and now they're complaining that the ride is too bumpy and the wind is a little much.
Don't whine about not getting to sit inside the car! Unchain yourself and go catch one of the cars where the doors are unlocked and open and the driver and other passengers are beckoning you to join them. (Apologies for the mangled metaphor.)
These folks come off to me like masochistic babies.
Well, there's your problem right there.
(I have sooooo much more in this vein but I'll spare you. ;-)
EDIT: No I won't. Fuck it. This is too ridiculous.
These guys (and they are all guys) chained themselves to github's metaphorical car and now they're complaining that the ride is too bumpy and the wind is a little much.
Don't whine about not getting to sit inside the car! Unchain yourself and go catch one of the cars where the doors are unlocked and open and the driver and other passengers are beckoning you to join them. (Apologies for the mangled metaphor.)
These folks come off to me like masochistic babies.
+1
Shouldn't we (the OSS community) have an open source, roll-your-own version of something like GitHub? Like, the repo-management equivalent to a phpBB or a Wiki or a Wordpress.
We do have the separate components, though maybe the hard part is to glue them together. But still, it is something what would be worth the time and effort, wouldn't it?
Shouldn't we (the OSS community) have an open source, roll-your-own version of something like GitHub? Like, the repo-management equivalent to a phpBB or a Wiki or a Wordpress.
We do have the separate components, though maybe the hard part is to glue them together. But still, it is something what would be worth the time and effort, wouldn't it?
I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developing in the open can't be done on platforms where restrictions apply, and they do apply. I'm saying this with no intention of sounding like a jerk, but 18 project maintainers and/or developer need to write an open letter to get Github to give'em a "me too" button? I understand the issue, but i still find it rather silly.
The only aspect I could think of where Github has the pro is the community of developers it has, but does it really matter that much? Especially for established/big projects that probably don't care about the fork/stars numbers, or the random look around-ers that pass by.
The only aspect I could think of where Github has the pro is the community of developers it has, but does it really matter that much? Especially for established/big projects that probably don't care about the fork/stars numbers, or the random look around-ers that pass by.
> I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain
You outlined exactly why people don't build their own or use another system. Github is the best there is. That doesn't mean it doesn't have problems, but if your company/project/expertise isn't focused in collaborative development and/or version control, you're just distracting yourself by building your own.
The authors are not saying "we can build a better Github." They have complaints and would like them resolved, but don't see a good way of having that happen.
You outlined exactly why people don't build their own or use another system. Github is the best there is. That doesn't mean it doesn't have problems, but if your company/project/expertise isn't focused in collaborative development and/or version control, you're just distracting yourself by building your own.
The authors are not saying "we can build a better Github." They have complaints and would like them resolved, but don't see a good way of having that happen.
> Github is the best there is.
Doesn't matter really as it's still a locked platform. The argument they're making is that they're developing in the open and they'd like some sort of expedited treatment because of the size of the project or because they're doing OSS. I don't think those two can go hand in hand all the way.
Doesn't matter really as it's still a locked platform. The argument they're making is that they're developing in the open and they'd like some sort of expedited treatment because of the size of the project or because they're doing OSS. I don't think those two can go hand in hand all the way.
The most important thing is not even that GitHub is the best but that everybody is used to GitHub.
The point about GitHub today is that being "the best there is" is as irrelevant to its continued success as "being the best microblogging service there is" is to Twitter's.
Open Source projects move to GitHub because their users are all already familiar with GitHub from all the other open source projects that use it. That means those people already have a user account, know how to check out your code, are able to file issues, and can probably make contributions even if they're not very familiar with git, for example using one of the GitHub integrated GUIs that will handhold you through making a PR. If you are an odd-duck project using some other infrastructure you don't have any of these advantages, and the barrier to entry for potential contributors is correspondingly larger.
For users having a near-monoculture of source code hosting has all the same advantages but reversed; it means they only need a single account, and that every process they learn — all of which are well documented across the web — is fully transferable between projects. It also gives them a recognised place to show off their own code, and increasingly people are asking for a link to a GitHub profile as part of a hiring process. This even happens at Mozilla, an organisation that doesn't actually use GitHub for its most prominent projects (but increasingly does for new things; the advantages I mention here are valuable even when you already have everything set up for using something else).
Another benefit enjoyed by projects that use GitHub is the plethora of tools designed to integrate with it; again little to do with the intrinsic merits of the tool and everything to do with network effects (although I will allow that the API is generally very good). So if you chose an alternative to GitHub you might miss out on IDE integration, Travis, landscape.io, reviewable.io, or any number of other third party tools that either exclusively work with GitHub or have smoother integration in the case of such a well-worn path.
Tools like reviewable.io are interesting because they are clearly making up for deficiencies in the GitHub platform itself. In that case it's the totally, utterly, useless code review functionality in stock GitHub. And there are many other things in the site that could stand to be improved. For example the notification system that either spams you with every comment from a repo or ensures that you miss anything you don't check via the web UI. The permissions system that makes it impossible to add commits to a PR against your own repository without losing all the metadata associated with the PR. The issue tracker that doesn't allow assigning issues to anyone other than a project admin. But, from a business point of view, none of these things matter because GitHub isn't popular for being the best. It's popular for having been good enough for long enough to become ubiquitous, and now not being so bad as to negate the enormous network effects.
So the core of the problem here is not whether or not the authors, or anyone else, can build a better GitHub. The problem is that even if they could it would have to be wildly, dramatically, better to even provide competition. And so people, without meaningful leverage, resort to writing open letters and hoping that they can drum up enough noise that someone at GitHub chooses to care.
Open Source projects move to GitHub because their users are all already familiar with GitHub from all the other open source projects that use it. That means those people already have a user account, know how to check out your code, are able to file issues, and can probably make contributions even if they're not very familiar with git, for example using one of the GitHub integrated GUIs that will handhold you through making a PR. If you are an odd-duck project using some other infrastructure you don't have any of these advantages, and the barrier to entry for potential contributors is correspondingly larger.
For users having a near-monoculture of source code hosting has all the same advantages but reversed; it means they only need a single account, and that every process they learn — all of which are well documented across the web — is fully transferable between projects. It also gives them a recognised place to show off their own code, and increasingly people are asking for a link to a GitHub profile as part of a hiring process. This even happens at Mozilla, an organisation that doesn't actually use GitHub for its most prominent projects (but increasingly does for new things; the advantages I mention here are valuable even when you already have everything set up for using something else).
Another benefit enjoyed by projects that use GitHub is the plethora of tools designed to integrate with it; again little to do with the intrinsic merits of the tool and everything to do with network effects (although I will allow that the API is generally very good). So if you chose an alternative to GitHub you might miss out on IDE integration, Travis, landscape.io, reviewable.io, or any number of other third party tools that either exclusively work with GitHub or have smoother integration in the case of such a well-worn path.
Tools like reviewable.io are interesting because they are clearly making up for deficiencies in the GitHub platform itself. In that case it's the totally, utterly, useless code review functionality in stock GitHub. And there are many other things in the site that could stand to be improved. For example the notification system that either spams you with every comment from a repo or ensures that you miss anything you don't check via the web UI. The permissions system that makes it impossible to add commits to a PR against your own repository without losing all the metadata associated with the PR. The issue tracker that doesn't allow assigning issues to anyone other than a project admin. But, from a business point of view, none of these things matter because GitHub isn't popular for being the best. It's popular for having been good enough for long enough to become ubiquitous, and now not being so bad as to negate the enormous network effects.
So the core of the problem here is not whether or not the authors, or anyone else, can build a better GitHub. The problem is that even if they could it would have to be wildly, dramatically, better to even provide competition. And so people, without meaningful leverage, resort to writing open letters and hoping that they can drum up enough noise that someone at GitHub chooses to care.
>but what I'd genuinely like to know is why don't big projects just move to their own thing?
Github is a great advertising and marketing platform for large OSS projects. Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge (sorry FOSShub, it was a bold try), with all that implies.
The thing I really don't get is why people use it for small projects. Like Facebook, Twitter and basically every other social media site out there, it's a drama factory. It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
That's the last thing small OSS projects need, and I'd have thought most 5-15 man projects would be vastly better off throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business. I acknowledge that this reduces discoverability by some amount and thus risks taking a hit to your developer acquisition, but I'd love to see some hard numbers on how much. I'd wager that much like the Apple app store, if you're not in the top 50 on github, you're no one.
But hey, I'm apparently an old fogey born young, and I prefer to self-host when I can, so maybe I'm just pointlessly resisting the tide of the inevitable or something.
Github is a great advertising and marketing platform for large OSS projects. Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge (sorry FOSShub, it was a bold try), with all that implies.
The thing I really don't get is why people use it for small projects. Like Facebook, Twitter and basically every other social media site out there, it's a drama factory. It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
That's the last thing small OSS projects need, and I'd have thought most 5-15 man projects would be vastly better off throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business. I acknowledge that this reduces discoverability by some amount and thus risks taking a hit to your developer acquisition, but I'd love to see some hard numbers on how much. I'd wager that much like the Apple app store, if you're not in the top 50 on github, you're no one.
But hey, I'm apparently an old fogey born young, and I prefer to self-host when I can, so maybe I'm just pointlessly resisting the tide of the inevitable or something.
@Sir_Substance - thank you for the kind mention. I agree with you but don't forget that any Empire will fall sooner or later. People work with enthusiasm at a new project, after a while this new excitement is replaced by greed because the financial thing becomes the most important aspect. At this stage I would say that GitHub is Google, SourceForge is Yahoo and FossHub aims to become DuckDuckGo. We need to improve so instead of throwing us at garbage we would appreciate a constructive criticism. Thank you!
The reason why I thought bigger projects would be more capable of handling this is because team size = more manpower obviously.
> Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge.
Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform. If it's the issue of getting people excited about the project to want to use it or join in and help, it'd be interesting to see if there are any numbers to back this up.
I'm not sure about sourceforge but i never thought of it as a serious thing for big project hosting before github came around.
> It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
Totally. This is a good point I think. I never understood the fascination with obsessive forking (edit: lol, after the letter moved to github it got 2 forks! WHY! https://github.com/dear-github/dear-github) just to apply a patch or change a line of code (there's a lot of those). It's a nice feature and all, but not really that useful imo. I'd like to see some data on forks that haven't been touched as well, amounting to garbage, outdated code basically.
> ... throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business...
The thing that bugs me the most about Github and the likes is this. It's slowly taking away the will or need to do this. Same as how the use of Slack/Gitter has somewhat eclipsed IRC in OSS world. From my experience, I learn a lot when I'm doing things I don't really want to do or I find tedious because I either discover that there's a detail that I don't understand well or it motivated me to write an automator to sort things out.
> so maybe I'm just pointlessly resisting the tide of the inevitable or something.
Wait until the fixation on cloud crap washes off and everything will be back to normal lol.
> Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge.
Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform. If it's the issue of getting people excited about the project to want to use it or join in and help, it'd be interesting to see if there are any numbers to back this up.
I'm not sure about sourceforge but i never thought of it as a serious thing for big project hosting before github came around.
> It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
Totally. This is a good point I think. I never understood the fascination with obsessive forking (edit: lol, after the letter moved to github it got 2 forks! WHY! https://github.com/dear-github/dear-github) just to apply a patch or change a line of code (there's a lot of those). It's a nice feature and all, but not really that useful imo. I'd like to see some data on forks that haven't been touched as well, amounting to garbage, outdated code basically.
> ... throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business...
The thing that bugs me the most about Github and the likes is this. It's slowly taking away the will or need to do this. Same as how the use of Slack/Gitter has somewhat eclipsed IRC in OSS world. From my experience, I learn a lot when I'm doing things I don't really want to do or I find tedious because I either discover that there's a detail that I don't understand well or it motivated me to write an automator to sort things out.
> so maybe I'm just pointlessly resisting the tide of the inevitable or something.
Wait until the fixation on cloud crap washes off and everything will be back to normal lol.
>Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform.
To be clear, I meant perform as in "tap dance routine" and was being metaphorical.
A large project on github gets more exposure than a large project not on github, because it regularly shows up in the "explore" section of the site. A small project on github gets no more exposure than a small project not on github, because it does not.
(I have no citation for this, it's based on my observations only)
To be clear, I meant perform as in "tap dance routine" and was being metaphorical.
A large project on github gets more exposure than a large project not on github, because it regularly shows up in the "explore" section of the site. A small project on github gets no more exposure than a small project not on github, because it does not.
(I have no citation for this, it's based on my observations only)
It's a momentum thing I think. A big part of the Github platform mirrors a social media platform. When you meet a developer, you check out what they're up to on Github just like you might check on a friend's status on Facebook. Like Twitter, it's a way to get your name out there.
Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.
The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.
The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
> Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.
There are multiple ways to go around this, OpenID, Mozilla Persona, or any third-party authenticator.
> The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
I see this more of an additional reason for big projects to move away from Github. It gives unwarranted legitimacy to everything on the platform.
There are multiple ways to go around this, OpenID, Mozilla Persona, or any third-party authenticator.
> The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
I see this more of an additional reason for big projects to move away from Github. It gives unwarranted legitimacy to everything on the platform.
I just realized that Persona is going to be discontinued. Unfortunate, but alternatives can be whipped up I guess.
https://developer.mozilla.org/en-US/Persona
> On November 30th, 2016, Mozilla will shut down the persona.org services. Persona.org and related domains will be taken offline.
https://developer.mozilla.org/en-US/Persona
> On November 30th, 2016, Mozilla will shut down the persona.org services. Persona.org and related domains will be taken offline.
We're currently working on exactly that. If you want to be part of this, swing by the channel. Details and backlog here:
https://github.com/letsauth/letsauth.github.io
https://github.com/letsauth/letsauth.github.io
Nice! I read what you guys have in the wiki, looks pretty interesting!
Along the same line of thought: there's a lot of momentum regarding tooling surrounding GitHub. Continuous integration works smoothly. Slack works smoothly. github/hub and ghi let you interact with the issues and repos from the command line. Vim, Emacs, Atom, and Sublime plugins exist to integrate with GitHub. While moving to another hosting platform might fix some things, there is a lot of solid tooling built around GitHub.
[deleted]
[deleted]
I feel like there is a great opportunity right now for anyone to make a Github replacement. Sounds like a lot of these features are sorely needed at the moment. Why has Github been complacent?
> I feel like there is a great opportunity right now for anyone to make a Github replacement.
There is GitLab, which is good and is FOSS in addition.
There is GitLab, which is good and is FOSS in addition.
I'm maintaining a GitLab instance for my team at work and it's been really great for us. I am pretty disappointed that the CE version doesn't include GitLab Pages, though, as that was the one feature I missed most from GitHub and GitLab Enterprise is outside of our budget at this time.
At a previous company, we did this in GitLab with a simple post receive hook that just checked out the gh_pages (or gl_pages) branch on a webserver configured w/ rewrite to serve at a proper path. We even were able to do one better and allow PHP since it was self hosted and we trusted the committers.
Thanks, good to hear.
As people can use GitLab Pages on GitLab.com for free, we felt the ability to host your own static pages was more interesting for larger teams, hence our decision to bring it to GitLab Enterprise Edition.
As people can use GitLab Pages on GitLab.com for free, we felt the ability to host your own static pages was more interesting for larger teams, hence our decision to bring it to GitLab Enterprise Edition.
By their very nature, git repos are one of the easiest things to migrate. Simply point at a new remote and push, and that's really it. It means that, unlike many other services, I could see GitHub being completely abandoned almost over night. If something better came along.
Agreed. This is the point of git. There is no centralized repository.
You would lose the issues.
There are lot of tools to migrate them. Example, github.com/babel/babel has migrated their issues to phabricator.babeljs.io
True, but thanks to the API and their relatively simple structure it's reasonably easy to at least copy their contents as well. Linking them correctly to user accounts on a new platform is probably the biggest issue.
Users with public SSH keys would be easy: https://github.com/JohnMaguire.keys
When a new user signs up, ask them for their existing Github username and to upload an SSH key that matches.
When a new user signs up, ask them for their existing Github username and to upload an SSH key that matches.
I am pretty sure that a potential competitor will use GitHub's APIs to import issues as well.
You say that like it is a bad thing...
The same reason YouTube is so popular. Neither GitHub or YouTube are big because of their technology, it's their community that keeps people there.
It's a huge tax on attention and contributions if a project decides not to use GitHub. There are many GitHub replacements but none of them have the community of GitHub.
It's a huge tax on attention and contributions if a project decides not to use GitHub. There are many GitHub replacements but none of them have the community of GitHub.
Playing devil's advocate - in their respective heydays, SourceForge and Google Code both seeemed unassailable. They had large, active communities that hosted the most popular OSS projects.
Could the same thing happen to GitHub?
Could the same thing happen to GitHub?
But it requires feature expansion on the scale of github, and a perpetual decline and ignorance of the community on the parts of the current host for years for that kind of transition to happen naturally.
That, and github has centralized development to a degree that sourceforge or gcode in 2008 could only dream of. It not only obsoleted other hosting solutions but also brought millions of developers into these kinds of development ecosystems whom used to just use forums or their own personal websites to host their projects.
That, and github has centralized development to a degree that sourceforge or gcode in 2008 could only dream of. It not only obsoleted other hosting solutions but also brought millions of developers into these kinds of development ecosystems whom used to just use forums or their own personal websites to host their projects.
For a very large percentage of young developers I work with, "Git" and "GitHub" are synonyms. GitHub has made themselves literally synonymous with version control to a large number of people. That's a lot of social momentum that a competitor has to overcome. In light of that, it's not that surprising at all that GitHub has become complacent.
Because those features are not ones from the people paying money to Github?
Most of these features are ones that only affect public projects. You're not customers of Github, you're the product. Or rather, the advertising.
Most of these features are ones that only affect public projects. You're not customers of Github, you're the product. Or rather, the advertising.
Because Github succeeded in being the Git repo host. I think you're on track with saying their complacency is an opportunity and I wouldn't doubt to see a Github killer born this year.
> I feel like there is a great opportunity right now for anyone to make a Github replacement. Sounds like a lot of these features are sorely needed at the moment. Why has Github been complacent?
Network effects strong enough to slow the growth of any competitor long enough for GitHub to adapt.
Network effects strong enough to slow the growth of any competitor long enough for GitHub to adapt.
That will be extremely challenging. GitHub has a huge community with a lot of heavy weight projects behind it. Sure you can add a few features on top of whatever you build, but GitHub has the ability to copy whatever seems popular very quickly.
They've pretty much been profitable since the start unlike other start-ups who may be more eager to please users/customers.
Why not bitbucket?
Most people on GitHub do not suffer these issues, simply put. It's only really the popular open source projects, which represents a small minority but are loud and vocal.
[deleted]
> Why has Github been complacent?
Management, money, growth.
Management, money, growth.
My company pays me to work on a fairly old-school free software project and we run our own git service. Our workflow is email based so we won't ever consider switching to GitHub.
That said, we do sometimes consider setting up an official mirror on GitHub. Ideology aside (some team members might think we shouldn't promote a propriety solution for free software project), the main thing that puts us off is that there is no way to disable pull requests. Closing all pull requests by hand is not appealing; leaving all pull requests open is not desirable. We can probably write a bot to close pull requests, but that is just yet another administrative burden.
Not sure if GitHub will ever consider allowing users to disable pull requests though. That seems to go against GitHub's core interest.
That said, we do sometimes consider setting up an official mirror on GitHub. Ideology aside (some team members might think we shouldn't promote a propriety solution for free software project), the main thing that puts us off is that there is no way to disable pull requests. Closing all pull requests by hand is not appealing; leaving all pull requests open is not desirable. We can probably write a bot to close pull requests, but that is just yet another administrative burden.
Not sure if GitHub will ever consider allowing users to disable pull requests though. That seems to go against GitHub's core interest.
FreeBSD has worked out a means of accepting pull requests on their github mirror, guessing using the API.
I myself don't really see any motive of doing that. It is administrative burden (maintaining the service that bridge API and existing system, managing GitHub accounts / tokens). Compare that to the number / quality of pull requests received [0] [1] and I find RoI of doing that very low.
[0] https://github.com/freebsd/freebsd/pulls [1] https://github.com/torvalds/linux/pulls
[0] https://github.com/freebsd/freebsd/pulls [1] https://github.com/torvalds/linux/pulls
I work on a very relevant project called Product Pains.
React Native, the open source project, is using Product Pains instead of GitHub issues for bug reports and feature requests. This is because there were thousands of open issues and, just as this document mentions, it's impossible to organize them. The comments are all "+1" and it's really hard to tell what's important and what's just noise.
If you take a look at https://productpains.com/product/react-native?tab=top you'll see the power of being able to vote on these issues.
So why's Product Pains relevant?
1. It's a temporary alternative to GitHub issues. I'm guessing GitHub will get to adding votes eventually. If you want to use Product Pains for organizing issues for your open source project, go for it. I'll even give it away to you for free.
2. It's a community dedicated to improving products. This document is chock-full of great, constructive, actionable feedback. Product Pains is a community built for posting exactly this. You can post feedback publicly, about any product, people can vote on it, and posts with a lot of votes create a social responsibility for the company to respond.
3. It's a way for your voice to be heard. Posting on Hacker News lasts a day and will get your voice heard. If you post actionable, constructive feedback on Product Pains, and 150 people vote on it, it lingers waiting for GitHub to do something about it. Around 600 users on Product Pains are also React Native developers. They'd probably be ecstatic to vote on constructive feedback for GitHub.
For example, go make an account and vote here: https://productpains.com/post/github/implement-voting-for-is...
React Native, the open source project, is using Product Pains instead of GitHub issues for bug reports and feature requests. This is because there were thousands of open issues and, just as this document mentions, it's impossible to organize them. The comments are all "+1" and it's really hard to tell what's important and what's just noise.
If you take a look at https://productpains.com/product/react-native?tab=top you'll see the power of being able to vote on these issues.
So why's Product Pains relevant?
1. It's a temporary alternative to GitHub issues. I'm guessing GitHub will get to adding votes eventually. If you want to use Product Pains for organizing issues for your open source project, go for it. I'll even give it away to you for free.
2. It's a community dedicated to improving products. This document is chock-full of great, constructive, actionable feedback. Product Pains is a community built for posting exactly this. You can post feedback publicly, about any product, people can vote on it, and posts with a lot of votes create a social responsibility for the company to respond.
3. It's a way for your voice to be heard. Posting on Hacker News lasts a day and will get your voice heard. If you post actionable, constructive feedback on Product Pains, and 150 people vote on it, it lingers waiting for GitHub to do something about it. Around 600 users on Product Pains are also React Native developers. They'd probably be ecstatic to vote on constructive feedback for GitHub.
For example, go make an account and vote here: https://productpains.com/post/github/implement-voting-for-is...
Bitbucket kills GitHub issues with these two features:
- Multiple assignees for an issue - An "Approve" button so that maintainers can stamp a PR with the seal of approval
- Multiple assignees for an issue - An "Approve" button so that maintainers can stamp a PR with the seal of approval
Surprised I didn't see my personal favourite mentioned - the unlimited free private repos!
To be fair, GitHub has to make money.
None of the complaints are about the GitHub business model, which is IMO pretty fair.
None of the complaints are about the GitHub business model, which is IMO pretty fair.
True, I guess with Atlassian it's different as their actual flagship product is Jira (and I assume the people who buy the paid-for BB packages are loyal to BB due to things like the free repos so it evens itself out).
GitLab offers pretty much the same as GitHub and is free (as in FLOSS).
Their hosted version also offers free unlimited private repositories.
I just wish that bitbucket's UI was half as smooth as Github. Sure, it's not terrible, but it has a lot of rough edges.
I'm completely comfortable calling BitBucket's UI/UX terrible.
Github kills Bitbucket with this one feature: uptime
...and speed in my experience. Both the web UI and push/pull.
I've used Bitbucket for years and I've never seen "multiple assignees for an issue" as something which is available. I've just looked at a couple of our (private) repositories and I still can't see how you would do it. Either that feature doesn't exist or it's used in an extremely obscure manner.
Yup, I love GH, use it every day, but issue management is the pits.
It'd be really nice if I could custom sort the queue of issues so that I know what's next up in my queue of things to do; right now I've got 5 tags called NextUp:1 -> NextUp:5 on each repo; this takes way more manual updating than a simple drag/drop widget.
Like they mentioned, having a voting system would be super useful for knowing what matters -- I cringe every time I leave a +1, so I've gotten into the habit of at least adding a comment after it --- but the premise and the pain are the same.
It'd be really nice if I could custom sort the queue of issues so that I know what's next up in my queue of things to do; right now I've got 5 tags called NextUp:1 -> NextUp:5 on each repo; this takes way more manual updating than a simple drag/drop widget.
Like they mentioned, having a voting system would be super useful for knowing what matters -- I cringe every time I leave a +1, so I've gotten into the habit of at least adding a comment after it --- but the premise and the pain are the same.
We created ZenHub - https://www.zenhub.io/ - specifically to solve these problems.
The addition of a task board in the GitHub interface allows you to communicate both the priority and progress of GitHub issues.
While adding a +1 button to comments allows feedback without clutter.
Best of all, it is free for Open Source :)
You can read more on why we created ZenHub here - https://medium.com/axiom-zen/introducing-zenhub-2-0-c352a12c... and get in touch with us via our public support repo here - https://github.com/zenhubio/support
I hope we can help improve your GitHub experience!
The addition of a task board in the GitHub interface allows you to communicate both the priority and progress of GitHub issues.
While adding a +1 button to comments allows feedback without clutter.
Best of all, it is free for Open Source :)
You can read more on why we created ZenHub here - https://medium.com/axiom-zen/introducing-zenhub-2-0-c352a12c... and get in touch with us via our public support repo here - https://github.com/zenhubio/support
I hope we can help improve your GitHub experience!
I agree with voting.
I also think that voting systems should only have /positive/ inputs. (I agree with the content of a given statement/post). Negatives belong as a concretely expressed /contrasting opinion/ which can, it's self, be 'agreed with' (voted for).
I also think that voting systems should only have /positive/ inputs. (I agree with the content of a given statement/post). Negatives belong as a concretely expressed /contrasting opinion/ which can, it's self, be 'agreed with' (voted for).
A shame that GitHub aren't more responsive to the community that enables their success when they make such a big deal of their openness. It is also our own fault that we have allowed ourselves to become dependent on a single provider of a relatively simple service.
That said, I'm extremely grateful to the platform for enabling collaboration on open source and to the company for its work on Git, Resque etc.
GitHub's strategy is to open source everything except the business critical stuff, but it seems to me that their business is in enterprise support rather than in actual software. Perhaps they should just open source the whole platform and count on their service business being enough to carry the company?
That said, I'm extremely grateful to the platform for enabling collaboration on open source and to the company for its work on Git, Resque etc.
GitHub's strategy is to open source everything except the business critical stuff, but it seems to me that their business is in enterprise support rather than in actual software. Perhaps they should just open source the whole platform and count on their service business being enough to carry the company?
I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems.
I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.
I do think there should be a +1/like button though.
I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.
I do think there should be a +1/like button though.
Have you ever tried to maintain a popular OS project on Github? Github issues feel great until you start using them at scale, and then they start to fall apart without some structure. This is especially pronounced in open source where many issues come from people who aren't familiar with what information you need in an issue to quickly resolve it.
I don't think the authors are requesting that this be made mandatory for all repos, but instead they just want the option to set up rules for repos they maintain. As someone giving up their free time to offer software for the rest of us, it seems only fair to let them set the rules about what they need before they can resolve an issue.
The biggest issue I see OSS maintainers running into is that they likely aren't the voice that Github listens to most anymore. If they can get some companies that pay for Github Enterprise to sign their letter as well that would likely help prioritize these features.
I don't think the authors are requesting that this be made mandatory for all repos, but instead they just want the option to set up rules for repos they maintain. As someone giving up their free time to offer software for the rest of us, it seems only fair to let them set the rules about what they need before they can resolve an issue.
The biggest issue I see OSS maintainers running into is that they likely aren't the voice that Github listens to most anymore. If they can get some companies that pay for Github Enterprise to sign their letter as well that would likely help prioritize these features.
My project's main repo has 150 issues (only 7 still open) and it works out pretty well. Usually contributors will answer each other's questions and help close issues.
I suppose that could be a problem if you have 7000+ issues (as is the case for Docker) - But those projects represent an extremely small percentage of all OSS projects on GitHub. Also, these projects usually have a lot of contributors, so maybe those contributors could help filter through and tag/close issues as necessary?
I suppose that could be a problem if you have 7000+ issues (as is the case for Docker) - But those projects represent an extremely small percentage of all OSS projects on GitHub. Also, these projects usually have a lot of contributors, so maybe those contributors could help filter through and tag/close issues as necessary?
The request was to allow maintainers to define a template or have the ability to add fields. So the formats would be on a project by project basis.
> Maybe if your software was better designed, people wouldn't be asking the question to begin with.
This is just silly.
> Maybe if your software was better designed, people wouldn't be asking the question to begin with.
This is just silly.
Not so. For my project, I noticed on several occasions that different people were asking the same questions and that prompted me to rethink the design of the project a bit and it greatly improved the community engagement as a result.
Why should maintainers not get annoyed if people ignore the proper support channels (which often have a great community of users to help) and further burden the developers instead?
>I wouldn't like to force people to adhere to a particular format when reporting problems.
The thing is, if they implemented issue formatting in the way the posted document describes, the default would be exactly what it is now. Giving maintainers more control can't possibly be a bad thing.
The thing is, if they implemented issue formatting in the way the posted document describes, the default would be exactly what it is now. Giving maintainers more control can't possibly be a bad thing.
I have mixed feelings about these requests. Yes it would be nice to have these extra features in GitHub. Its issue handling has always been a bit light on the workflow side—but IMHO has made up for it with a pleasant way to organize conversation around issues. The simple and smooth UX is part of what makes GitHub so great.
For the opposite side of the spectrum, there's the Bitbucket+Jira combo. It is customizable to a PM's heart's content, and in the process can become a mess of a tool.
For the opposite side of the spectrum, there's the Bitbucket+Jira combo. It is customizable to a PM's heart's content, and in the process can become a mess of a tool.
I have mixed feelings about custom fields, I'd like Github UI to become as burden as Jira, but in the other hand 'reactions' as Slack or Facebook are implementing would make much easier to follow a discussion without so much scroll down.
After the whole incident where they deleted forks of a project without notice, due to their belief on what is and is not appropriate words to use in code without an apology I think we really need to re-assess GitHub in general.
Their 'control' of code and lack of respect to the people running projects is very disappointing and they seem to not want to move forward on the issues.
I'm surprised the open community is allowing this de-facto ownership of the worlds code and how it's written to take place, I'm not so sure they are a benevolent dictator.
https://www.techdirt.com/articles/20150802/20330431831/githu...
Their 'control' of code and lack of respect to the people running projects is very disappointing and they seem to not want to move forward on the issues.
I'm surprised the open community is allowing this de-facto ownership of the worlds code and how it's written to take place, I'm not so sure they are a benevolent dictator.
https://www.techdirt.com/articles/20150802/20330431831/githu...
Interesting petition, and I agree with it; but I wonder why are all projects mentioned in the _Signed by_ section based on JavaScript? I know there are other languages involved in some of those projects like C++ and Java in Selenium and PhantomJS but this specific thing in the document makes me believe that only JavaScript developers _(at least the ones using GitHub)_ are more prone to complain than other type of developers.
It's simple: This was made by a JS developer who shared it on Twitter and whose followers/community friends are more likely to be JS developers.
> why are all projects mentioned in the _Signed by_ section based on JavaScript?
I also noticed that most of the repositories seem to be based on Javascript.
> JavaScript developers _(at least the ones using GitHub)_ are more prone to complain than other type of developers.
My guess:
Based on numerous sources [1][2], Javascript is the most popular language on GitHub. So there are more developers, more repositories, more activity involved. It just happens that one (or a few of them) talked this through and gather up other folks in their community.
[1] http://githut.info [2] https://github.com/blog/2047-language-trends-on-github
I also noticed that most of the repositories seem to be based on Javascript.
> JavaScript developers _(at least the ones using GitHub)_ are more prone to complain than other type of developers.
My guess:
Based on numerous sources [1][2], Javascript is the most popular language on GitHub. So there are more developers, more repositories, more activity involved. It just happens that one (or a few of them) talked this through and gather up other folks in their community.
[1] http://githut.info [2] https://github.com/blog/2047-language-trends-on-github
The problem is that GitHub has a monopoly and is considered _the_ current standard for Open Source. But I think that once some of the major projects move to alternatives like GitLab (which has many of the features described in that letter) GitHub will have to obey its user base. Unfortunately no Open Source project with a large user base will dare to do the first step.
There are some open source projects with a large user base taking the step to us, for example https://gitlab.com/mailman/mailman
Regarding the three demands in the doc:
1. GitLab has issue templates in EE and on GitLab.com https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/28
2. GitLab has the award emoji function that doesn't spam and acts as a voting system https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
3. We're open to displaying CONTRIBUTING.md more prominently, please open an issue on our public issue tracker that contains all our planned features https://gitlab.com/gitlab-org/gitlab-ce/issues
I'll go sleep now but please ask any questions so I can respond tomorrow.
Regarding the three demands in the doc:
1. GitLab has issue templates in EE and on GitLab.com https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/28
2. GitLab has the award emoji function that doesn't spam and acts as a voting system https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
3. We're open to displaying CONTRIBUTING.md more prominently, please open an issue on our public issue tracker that contains all our planned features https://gitlab.com/gitlab-org/gitlab-ce/issues
I'll go sleep now but please ask any questions so I can respond tomorrow.
Yes, I already saw some of these.
Unfortunately, there's no Travis CI integration yet, which I've been using on GitHub a lot.
I'm evaluating GitLab CI right now. Am I right, that I have to host a runner myself if I don't want to use a shared runner for my project?
> You can setup as many runners as you need. Runners can be placed on separate users, servers, and even on your local machine.
Does "local machine" really mean a non-public machine like my notebook?
Appreciating help from GitLab's CEO :)
Unfortunately, there's no Travis CI integration yet, which I've been using on GitHub a lot.
I'm evaluating GitLab CI right now. Am I right, that I have to host a runner myself if I don't want to use a shared runner for my project?
> You can setup as many runners as you need. Runners can be placed on separate users, servers, and even on your local machine.
Does "local machine" really mean a non-public machine like my notebook?
Appreciating help from GitLab's CEO :)
We would love for Travis CI to offer support for GitLab, they can use our new commit status API.
But you'll find that GitLab CI is a pretty complete replacement. If you don't want to use a shared runner you indeed have to use a shared runner.
Running on your local machine can indeed include your notebook.
But you'll find that GitLab CI is a pretty complete replacement. If you don't want to use a shared runner you indeed have to use a shared runner.
Running on your local machine can indeed include your notebook.
We're working on a response to all the issues in the letter in https://gitlab.com/gitlab-org/gitlab-ce/issues/8938
We've published our response https://about.gitlab.com/2016/01/15/making-gitlab-better-for...
I went ahead and created an account on GitLab.com. So far I can tell the transition is seamless. You can import a repository from GitHub with only a few clicks. Issues will be inherited, but the single PR on the repo I tried to migrate got lost on the way.
Importing Pull Requests will be possible with the next version of gitlab that's going to be released on the 22nd january.
See this MR for more information:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2168
Github needs two major features: 1. discussion groups for users vs. devs as people use issues for it currently. and 2. A searchable "license" attribute for all projects with standard license templates for MIT/Apache/GPL/etc... When looking for a source code, you need to consider the platform, language and license.
"It's the world's tiniest open source violin"
https://xkcd.com/743/
https://xkcd.com/743/
Each and every suggestion is a sane and much needed improvement.
I completely agree with some of these suggestions, but it doesn't need all of them. If you really need a heavily-customizable issue tracking system, you can do anything you want in Bugzilla or Jira.
Every checkbox, dropdown and mandatory field they add makes GitHub Issues less attractive to those who don't need it. Simplicity is a feature, and it's one that you sacrifice as you make your software more flexible.
Every checkbox, dropdown and mandatory field they add makes GitHub Issues less attractive to those who don't need it. Simplicity is a feature, and it's one that you sacrifice as you make your software more flexible.
I guess it depends who is logging issues. If I'm experiencing some bug that I need fixed and motivated enough to log an issue at all, I'm probably motivated enough to fill out a few more fields.
Especially the +1
Best github support thread ever : https://github.com/isaacs/github/issues/9 (scroll down)
I made a similar issue here: https://src.sourcegraph.com/issues-playground/.tracker/26
I don't think a +1 button would help.
Google Code had stars in order to encourage people to +1 something without creating noise and then instead of +1 comments you got +1 comments AND people yelling at them for using it wrong.
Google Code had stars in order to encourage people to +1 something without creating noise and then instead of +1 comments you got +1 comments AND people yelling at them for using it wrong.
At Sourcegraph, we're trying to help solve these problems for developers everywhere (https://sourcegraph.com), both in open source and inside companies. GitHub’s commercial success and contributions to the world of development are impressive (and I'm speaking as a GitHub user for 8 years), but they can’t build everything developers need on their own.
We’re really pumped about improving dev team collaboration in the GitHub ecosystem by (soon) letting anyone use Sourcegraph.com’s code intelligence (semantic search/browsing), improved pull requests, flexible issue tracking with Emoji reactions instead of +1s (example: https://src.sourcegraph.com/sourcegraph/.tracker/151), etc.—all on their existing GitHub.com repositories.
All of Sourcegraph’s source code is public and hackable at https://src.sourcegraph.com/sourcegraph, so it can grow over time to solve the changing needs of these projects. (It’s licensed as Fair Source (https://fair.io), not closed source like GitHub or open source.)
Email me ([email protected]) if you’re interested in beta-testing this on your GitHub.com repositories.
We’re really pumped about improving dev team collaboration in the GitHub ecosystem by (soon) letting anyone use Sourcegraph.com’s code intelligence (semantic search/browsing), improved pull requests, flexible issue tracking with Emoji reactions instead of +1s (example: https://src.sourcegraph.com/sourcegraph/.tracker/151), etc.—all on their existing GitHub.com repositories.
All of Sourcegraph’s source code is public and hackable at https://src.sourcegraph.com/sourcegraph, so it can grow over time to solve the changing needs of these projects. (It’s licensed as Fair Source (https://fair.io), not closed source like GitHub or open source.)
Email me ([email protected]) if you’re interested in beta-testing this on your GitHub.com repositories.
I think reactions as implemented in Facebook, Slack or Sourcegraph is a really neat UX solution for the +1 spam problem.
My biggest gripe with GitHub has been the notification system. Personally I can't use the web UI for notifications because they bundle multiple notifications per issue. This leads to potentially missed notifications since it is up to me to scan the issue/PR for new comments.
My workaround has been to use email notifications exclusively. I have a Gmail filter that applies a label to all notifications and skips the inbox. Then in my mail client I have a smart mailbox that only shows me unread notifications with that label (or that folder, from an IMAP perspective). The smart mailbox then shows me a counter of unread notifications. This way I don't oversee comments when multiple ones are made in a PR.
Problem 1: No context in these notifications. It would be nice if these emails could show the code in question for diff comments or the entire comments thread.
Problem 2: Now what is really bad with these notification emails is that the link "view it on GitHub" sometimes no longer links to the comment I'm being notified of. This happens when the comment was made on a PR on a line of the diff that no longer exists, as sometimes is the case when new commits are pushed. I then have to go to the main PR page, expand all collapsed "foo commented on an outdated diff" comments and manually search for the comment in order to get the context and be able to reply.
By fixing problem 1, problem 2 would be automatically fixed with it and make my workflow much more productive. Is there anyone else annoyed by this?
My workaround has been to use email notifications exclusively. I have a Gmail filter that applies a label to all notifications and skips the inbox. Then in my mail client I have a smart mailbox that only shows me unread notifications with that label (or that folder, from an IMAP perspective). The smart mailbox then shows me a counter of unread notifications. This way I don't oversee comments when multiple ones are made in a PR.
Problem 1: No context in these notifications. It would be nice if these emails could show the code in question for diff comments or the entire comments thread.
Problem 2: Now what is really bad with these notification emails is that the link "view it on GitHub" sometimes no longer links to the comment I'm being notified of. This happens when the comment was made on a PR on a line of the diff that no longer exists, as sometimes is the case when new commits are pushed. I then have to go to the main PR page, expand all collapsed "foo commented on an outdated diff" comments and manually search for the comment in order to get the context and be able to reply.
By fixing problem 1, problem 2 would be automatically fixed with it and make my workflow much more productive. Is there anyone else annoyed by this?
> Personally I can't use the web UI for notifications because they bundle multiple notifications per issue. This leads to potentially missed notifications since it is up to me to scan the issue/PR for new comments.
I think the bundling aspect is an awesome feature! I can read multiple new comments all at once, with context in mind and less total context switches.
About being able to miss new comments - doesn't the link in the notifications UI take you directly to the first unread comment?
I think the bundling aspect is an awesome feature! I can read multiple new comments all at once, with context in mind and less total context switches.
About being able to miss new comments - doesn't the link in the notifications UI take you directly to the first unread comment?
I just created and maintain a little Android library (a very rewarding experience by the way) so most of the complaints about Github doesnt really apply to me because the size and reach of my project (I understand the point perfectly though).
But I read some complaints about the users and the issues they tend to open and I fully agree. They are a minority but I can't only imagine what people with bigger projects have to deal with. This is what I've found:
- People with little to zero experience in the language/framework that simply state that my project doesn't work without providing more information and sometimes they didn't reply to my "give me more info" inquiries.
- Guys who just want to get their homework done and They are basically trying to get it done using me as non-paid freelance.
- And my favourite one, junior dev in a company, he needs to get their work done with more pressure than the previous one so became anxious about their problems and I feel it even via email. Eventually He gets the thing done but He notices I changed the build system to Jitpack for better dependency handling and and start to complain about Man in the middle attacks to his company and black-hat hackers replacing my lib with a malicious one (I guess it could happen but come on).
But it is a very rewarding experience besides these anecdotical cases
But I read some complaints about the users and the issues they tend to open and I fully agree. They are a minority but I can't only imagine what people with bigger projects have to deal with. This is what I've found:
- People with little to zero experience in the language/framework that simply state that my project doesn't work without providing more information and sometimes they didn't reply to my "give me more info" inquiries.
- Guys who just want to get their homework done and They are basically trying to get it done using me as non-paid freelance.
- And my favourite one, junior dev in a company, he needs to get their work done with more pressure than the previous one so became anxious about their problems and I feel it even via email. Eventually He gets the thing done but He notices I changed the build system to Jitpack for better dependency handling and and start to complain about Man in the middle attacks to his company and black-hat hackers replacing my lib with a malicious one (I guess it could happen but come on).
But it is a very rewarding experience besides these anecdotical cases
It's the nature of any issue tracker to gather low-quality feedback. The people using the product who are happy with it or who can solve their own problems mostly aren't the ones booking issues, unless there are genuine bugs. Paradoxically, a high quality project will have fewer genuine issues to report, and therefore be sensitive to a lower average quality of feedback.
Hi. your junior colleague might be interested in the security answer here https://jitpack.io/docs/FAQ/. It's an important matter so will be happy to answer any more questions via email/gitter.
You can also run JitPack on-premises and have full control over build artifacts.
You can also run JitPack on-premises and have full control over build artifacts.
Fortunately not my junior colleague! just a junior dev using my lib in his company's project. Thank you for the FAQ. I will forward it to him
All this problems seem to me like good problems to have.
They all seem to stem from the fact that github is too successful. And too many people are on github and too many people are using it, often in wrong ways.
Of course github should solve them all. But still, it's still better to have problems with too many people and too much interest, than have the opposite problem - dying platform that people are leaving (see: sourceforge and Google Code).
They all seem to stem from the fact that github is too successful. And too many people are on github and too many people are using it, often in wrong ways.
Of course github should solve them all. But still, it's still better to have problems with too many people and too much interest, than have the opposite problem - dying platform that people are leaving (see: sourceforge and Google Code).
It's not a good problem for the Open Source community after all.
Being too successful is of course a good problem for github to have, but for the individual maintainers, it's still a source of frustration that can lead to maintainer burnout. If too many people get frustrated and leave, then it can quickly turn from a problem of too many people to having too few.
Look at kallithea SCM at http://kallithea-scm.org/, we have used it and in most cases it works well. Also it supports both git and mercurial. Python should learn a lesson when they decided to move their repository to closed source system like github. But obviously as people use Facebook, developers use github for the same reason, network effect.
A lot of these points are fair and interesting, but I fail to grab some of the points, especially that one:
Why blocking a whole organization from an open source project? What would prevent such users to use a personal account instead to do what they organization counterpart is blocked from anyways?
Ability to block users from an organization.
Why blocking a whole organization from an open source project? What would prevent such users to use a personal account instead to do what they organization counterpart is blocked from anyways?
A more plausible interpretation would be that a particular GitHub organization might wish to block the inputs of a particular user across all its projects. That is, the phrase "from an organization" is adverbial and clarifies "block" rather than "users".
You're probably right! I don't use organization accounts so I'm not sure what was the issue, it would be to prevent haters to troll on every project of a particular company?
Yes that would make sense to me, but keep in mind that any user may create an "organization", so this might just be a bunch of repos associated with e.g. a particular framework rather a particular company.
I work at a large company with a central GitHub Enterprise instance, and we use GitHub as a code-reviewing and code-hosting platform. Everything else (including build-automation) is integrated through web-hooks to Atlassian tools for many of the reasons noted in this letter. It works for us, but I am hopeful that GitHub will listen and maybe someday we can have everything on there.
I actually disagree with some of these suggestions, I find the simplicity of Github issues is what makes it so great. I think this should be solved with 3rd party tools, such as waffle.io
While I don't maintain Ansible anymore, +9 billion on this. GitHub is hard at scale.
GitHub is fantastic because everyone is on it, but the issue system has not improved since inception - and I felt the UI changes have actually stepped back.
We had to implement our own bot to comment on tickets that did not appear to follow a template, and I would have given a kingdom for a template that let people filter their own tickets into whether they were bugs or feature requests or doc items.
We also had a repo of common replies we copy and pasted manually (this because there was so much traffic and me replying quickly would likely tick someone off - but this too could have been eliminated mostly with a good template system). Having this built-in (maybe I could have picked a web extension) would have also been helpful.
So many hours lost that could have been features or bugfixes - and by many, I mean totally weeks, if not cumulative months.
GitHub does the world a great service, and I love it, but this would help tons.
I always got a response when I filed a ticket - ALWAYS - but a lot of them were in the "we'll take that under consideration" type vein.
I feel opening GitHub RFEs up to votes is probably not the answer to serve the maintainer side of the equation, since users outnumber maintainers, but these needs to be done and would greatly improve OSS just based on expediting velocity.
If you don't use the GitHub tracker you lose out on a lot of useful tickets. However, if you use it, you are pretty much using the most unsophisticated tracker out there.
It's good because there's a low barrier to entry, but just having a template system - a very very very basic one, would do wonders.
A final idea is that GitHub really should have a mailing list or discussion system. Google Groups sucks for moderation, and I THINK you could probably make something awesome. Think about how Trac and the Wiki were integrated, for instance, and how you could automatically hyperlink between threads and tickets. The reason I say this is often GitHub creates a "throw code at project" methodology, which is bound to upset both contributor and maintainer - when often a "how should I do this" discussion first saves work. Yet joining a Google Group is a lot of commitment for people, and they probably don't want the email. Something to think about, perhaps.
Also think about StackOverflow. It's kind of a wasteland of questions, but if there was a users-helping-users type area, it would reduce tickets that were not really bugs, but really requests for help. These take time to triage, and "please instead ask over here and join this list" causes people pain.
I love all the work to keep up site reliability, maybe I'd appreciate more/better analytics, but I totally say this wearing a GitHub octocat shirt at the moment.
GitHub is fantastic because everyone is on it, but the issue system has not improved since inception - and I felt the UI changes have actually stepped back.
We had to implement our own bot to comment on tickets that did not appear to follow a template, and I would have given a kingdom for a template that let people filter their own tickets into whether they were bugs or feature requests or doc items.
We also had a repo of common replies we copy and pasted manually (this because there was so much traffic and me replying quickly would likely tick someone off - but this too could have been eliminated mostly with a good template system). Having this built-in (maybe I could have picked a web extension) would have also been helpful.
So many hours lost that could have been features or bugfixes - and by many, I mean totally weeks, if not cumulative months.
GitHub does the world a great service, and I love it, but this would help tons.
I always got a response when I filed a ticket - ALWAYS - but a lot of them were in the "we'll take that under consideration" type vein.
I feel opening GitHub RFEs up to votes is probably not the answer to serve the maintainer side of the equation, since users outnumber maintainers, but these needs to be done and would greatly improve OSS just based on expediting velocity.
If you don't use the GitHub tracker you lose out on a lot of useful tickets. However, if you use it, you are pretty much using the most unsophisticated tracker out there.
It's good because there's a low barrier to entry, but just having a template system - a very very very basic one, would do wonders.
A final idea is that GitHub really should have a mailing list or discussion system. Google Groups sucks for moderation, and I THINK you could probably make something awesome. Think about how Trac and the Wiki were integrated, for instance, and how you could automatically hyperlink between threads and tickets. The reason I say this is often GitHub creates a "throw code at project" methodology, which is bound to upset both contributor and maintainer - when often a "how should I do this" discussion first saves work. Yet joining a Google Group is a lot of commitment for people, and they probably don't want the email. Something to think about, perhaps.
Also think about StackOverflow. It's kind of a wasteland of questions, but if there was a users-helping-users type area, it would reduce tickets that were not really bugs, but really requests for help. These take time to triage, and "please instead ask over here and join this list" causes people pain.
I love all the work to keep up site reliability, maybe I'd appreciate more/better analytics, but I totally say this wearing a GitHub octocat shirt at the moment.
I could rant for hours about all the things GitHub doesn't do (or does wrong) for "real" software development.
+1 from the Kubernetes project
+1 from the Kubernetes project
I wish Github would add a "Discussions" tab for repos, so projects don't need to create a separate Google Group (which require a Google account!) for questions-that-are-not-quite-issues.
There are three groups within GitHub, and this article is about the issues faced by the first - big open source projects (a small number).
The main bread and butter of GitHub is from private or organizational projects and do not have these issues
The majority of accounts on GitHub are folks like the majority of HN readers - developers, coders, hackers and do not have these issues.
So all these complaints are in a sense not applicable to the vast majority of both GitHubs revenue generating customers and the vast majority of GitHub users.
The main bread and butter of GitHub is from private or organizational projects and do not have these issues
The majority of accounts on GitHub are folks like the majority of HN readers - developers, coders, hackers and do not have these issues.
So all these complaints are in a sense not applicable to the vast majority of both GitHubs revenue generating customers and the vast majority of GitHub users.
While I like to bitch and moan about stuff myself, I don't really agree with the first point.
What I like about GitHub's issue tracking is that (compared with alternatives, such as Redmine or Jira) it is free form. It doesn't force users to fill information such as steps to reproduce and I don't think it should. And that's because the needs of every project is slightly different. Consider how different the "steps to reproduce" are for a web user interface, versus the usage of some library. Yes, it can be painful for an issue to not provide all the information required, but on the other hand GitHub does a better job than alternatives at fostering conversations and keeping people in the loop. I've even seen projects use the GitHub issues as some sort of mailing list.
On the second point, I do agree that GitHub needs a voting system for issues. Given that GitHub has long turned into some sort of social network, adding a voting system for issues is a no-brainer. But then a voting system doesn't address the problem of people getting frustrated about issues taking too long to get fixed. +1's are annoying, but sometimes that's a feature and I've been on both sides of the barricade.
What I like about GitHub's issue tracking is that (compared with alternatives, such as Redmine or Jira) it is free form. It doesn't force users to fill information such as steps to reproduce and I don't think it should. And that's because the needs of every project is slightly different. Consider how different the "steps to reproduce" are for a web user interface, versus the usage of some library. Yes, it can be painful for an issue to not provide all the information required, but on the other hand GitHub does a better job than alternatives at fostering conversations and keeping people in the loop. I've even seen projects use the GitHub issues as some sort of mailing list.
On the second point, I do agree that GitHub needs a voting system for issues. Given that GitHub has long turned into some sort of social network, adding a voting system for issues is a no-brainer. But then a voting system doesn't address the problem of people getting frustrated about issues taking too long to get fixed. +1's are annoying, but sometimes that's a feature and I've been on both sides of the barricade.
Do the undersigned send any money to github? It might be better to phrase your demand in the form of a question, "how much can we pay you to do this work for us?"
GitHub's success is based on its community. Simple fairness says the community should be respected and listened to, simple business says if the community doesn't get something back, it will get pissed and go somewhere else.
GitHub is a service, not a contracted vendor for work. There's a big difference.
[deleted](2)
GitHub got to where it is today thanks to the network effect that the undersigned helped create. If open source were to do a mass migration to another provider, many of the contributors whom are paying for private repositories and other features would most likely follow.
Yes, I do. If it was OSS I would PR the feature personally.
So most of the above replies seem to be a threat. Give us free stuffs. You have a nice website there, be a shame if anything happened to it.....
Seems like the Tony Soprano way of doing things.
Seems like the Tony Soprano way of doing things.
Is there an issue tracking system out there that works on top of the Github issue system?
This tracker app [0] is designed to be pretty modular, and there's a service implementation that uses the GitHub API client [1]. In theory, you could modify it and expand it to cover your custom needs for issue tracking.
[0] https://src.sourcegraph.com/apps/tracker
[1] https://godoc.org/src.sourcegraph.com/apps/tracker/issues/gi...
[0] https://src.sourcegraph.com/apps/tracker
[1] https://godoc.org/src.sourcegraph.com/apps/tracker/issues/gi...
We would love your thoughts on ZenHub.io [1] - fully integrated issue tracking, +1, estimates, burndown charts, kanban boards, even a personal todo list - a lot of the features asked for here, right within the GitHub interface and presented a lot more cleanly than competing products.
Disclosure: I work on ZenHub :)
[1] https://www.zenhub.io
Disclosure: I work on ZenHub :)
[1] https://www.zenhub.io
Looks nice. How do I add additional organizations after the first one? Can I send an invite to other organization managers to make themselves available for ZenHub?
Thanks!
Thanks!
Each organization is treated separately, all you need to do is install the extension and visit a repo of the other org. From there you'll start a 2 week trial and you'll be able to invite your team members and managers :)
waffle.io does this, but having to run on top of GitHub means it can't really fix problems like voting. But it can offer better search and things like that
+1 to the notification spam. Being @sam on github sucks sometimes. And as far as I can figure out there's no way to set watching/following/notifications to opt-in only.
So every time someone who knows a "Sam" uses @sam incorrectly in an issue I get notified, have to unsubscribe, ignore, and leave a polite message to let them know they're doing it wrong.
It's really lame that they've never fixed this.
So every time someone who knows a "Sam" uses @sam incorrectly in an issue I get notified, have to unsubscribe, ignore, and leave a polite message to let them know they're doing it wrong.
It's really lame that they've never fixed this.
Most of this stuff seems pretty common sense and reasonable. I really only have a couple of objections:
* Issue templating.
It's one thing to prefill the entry box, it's quite another to add fields that everyone must fill out. I quite like that filling out something on Github is totally the opposite of filling out something on Jira.
* Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines
This is a people problem that has plagued open source from day one. You cannot engineer your way around it in a manner that doesn't annoy your contributors.
There was a blurb in here about getting rid of the big green "new pull request" button, but that was when this link went to a google doc. Good - if someone doesn't want to take PR's, then they have almost no reason to be on Github in the first place. Put another way, it's the mark of someone that wants a repo as a signpost of sorts without actually interacting with its community.
* Issue templating.
It's one thing to prefill the entry box, it's quite another to add fields that everyone must fill out. I quite like that filling out something on Github is totally the opposite of filling out something on Jira.
* Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines
This is a people problem that has plagued open source from day one. You cannot engineer your way around it in a manner that doesn't annoy your contributors.
There was a blurb in here about getting rid of the big green "new pull request" button, but that was when this link went to a google doc. Good - if someone doesn't want to take PR's, then they have almost no reason to be on Github in the first place. Put another way, it's the mark of someone that wants a repo as a signpost of sorts without actually interacting with its community.
I think if these people have that many issues with GitHub, they should find a replacement. That's what happened in the Node community and it led to a better Node. That's a big list of complaints and GitHub doesn't have much incentive to fix 'em except to silence a bunch of cry babies that are bitching about a free tool.
I've felt the same way. The worst bit is notifications, so I get a notification that someone replied to an issue I opened. How do I get there? It's not in my notification page, I have to go to the email and click the link from there. Things get missed.
GitHub needs to step it up. They got to the top first, but can they stay there?
GitHub needs to step it up. They got to the top first, but can they stay there?
What I don't get ... why do people building free software even consider forcing their users and in particular their contributors to use proprietary development tools such as github? (Or, for that matter, exclude people from contributing to their projects who only use free software.)
Next, we'll see public complaints to Microsoft because MS Word doesn't properly support the way they want to maintain their project's documentation?
I mean, sure, feel free to complain all you like, but how is this not exactly what was to be expected from the beginning, and why do you expect them to care in the future, given that you just seem to have realized that they didn't care in the past, for obvious reasons, and given that their incentives haven't changed, and there is no reason for them to change in the future?
Next, we'll see public complaints to Microsoft because MS Word doesn't properly support the way they want to maintain their project's documentation?
I mean, sure, feel free to complain all you like, but how is this not exactly what was to be expected from the beginning, and why do you expect them to care in the future, given that you just seem to have realized that they didn't care in the past, for obvious reasons, and given that their incentives haven't changed, and there is no reason for them to change in the future?
Many times, I've asked GitHub to add icons for :test:, :doc:, :admin: and a couple others. I use them in commit messages as it helps categorize the type of commit. This has to be the easiest kind of improvement imaginable, but they have never bothered.
I know they've only recently released new permissions for organisations, but they're still extremely lacking. As far as I can see, there's no way of setting permissions at a group level.
As an example of how this would be used, we have a Github team within our organisation which is used for non-technical people to post bugs. These people have no reason to be able to see or push code to the repository, they only need to be able to create issues. This applies to every repository in the organisation. As far as I can see, and without manually adding every single repository to the team, there's no way of setting global permissions permissions for a team. This seems like a major oversight to me.
As an example of how this would be used, we have a Github team within our organisation which is used for non-technical people to post bugs. These people have no reason to be able to see or push code to the repository, they only need to be able to create issues. This applies to every repository in the organisation. As far as I can see, and without manually adding every single repository to the team, there's no way of setting global permissions permissions for a team. This seems like a major oversight to me.
I just create a single repo for all issues, cross repo, and manage it with waffle.io. Works well for me, but ymmv
I suspect they are focusing on developing their enterprise offering.
Anyway, I found that http://feathub.com/ addressed my frustration about the absence of a voting system.
Anyway, I found that http://feathub.com/ addressed my frustration about the absence of a voting system.
I would just love if they could add target _blank on all the links in comments and issues. I'm constantly navigating away from the issue to view links in question and then realizing the tab with the issue is gone.
My experience with Github support is terrible, if not one of the worst, I once had an issue and contacted their support and it took them 1 month to respond to me (literally) I was really surprised by that.
I had the opposite experience. I am on the free student plan for private repos. It has to be renewed annually. It wasn't clear to my how to do so. I asked, and Scott from Github support contacted me in under a minute and sorted it out. I was very impressed.
I contacted them dozens of times in 4 years and never had to wait more than a day. I guess you’ve been unlucky that time.
It's also annoying that Github sometimes is missing some basic features like attachments to bug reports and comments for instsance. All mature bug trackers have such feature.
Why do you want GitHub to solve the (very) specific problems of issue and defect tracking?
They make a facility available as a nicety, but if your project has legitimate Global impact, you should be looking at (or bootstrapping) a counterpart.
Don't have the revenue for JIRA? Apply for the Free license.
Don't have the stomach for Bugzilla? Turn out a Node/Go alternative.
Don't have the business alignment with Clearquest or Rally? Lower your expectations to suit your Free (as in beer) SCM tool.
They make a facility available as a nicety, but if your project has legitimate Global impact, you should be looking at (or bootstrapping) a counterpart.
Don't have the revenue for JIRA? Apply for the Free license.
Don't have the stomach for Bugzilla? Turn out a Node/Go alternative.
Don't have the business alignment with Clearquest or Rally? Lower your expectations to suit your Free (as in beer) SCM tool.
There's a lot of great feature requests for issues at the bottom of the document. Not sure why the document highlights only 3 things above the signatures.
Yet, I 100% agree with them. I do not understand why Github issues are so basic. The only feature I feel was added in all of 2015 was making the logging of every metadata change extremely verbose (read: maybe too noisy now?!).
"Person assigned to the issue"
"Person added label"
"Person removed label"
Yet, I 100% agree with them. I do not understand why Github issues are so basic. The only feature I feel was added in all of 2015 was making the logging of every metadata change extremely verbose (read: maybe too noisy now?!).
"Person assigned to the issue"
"Person added label"
"Person removed label"
I personally experiencing this issue. i wrote about this in 2014, you can check here http://paritosh.passion8.co.in/post/96619506751/dear-github-...
although i am addressing the problem in different way but the issue is same.
Don’t make it so easy to submit bad PRs
[0] https://github.com/technion/maia_mailguard/pull/42
Haha what a crazy final exchange.
> uh oh, someone is still sulking [...] We really don't care about the drama
Oh, okay buddy.
> uh oh, someone is still sulking [...] We really don't care about the drama
Oh, okay buddy.
[deleted]
GitHub also does not allow deletion of bullshit issues.
I get that these are super frustrating issues for these people (cough guys) that maintain these repos, but there's something telling about it that it's all JS people. That last cute lil paragraph really sums it up for me:
> Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!
LOL. I can't tell if this is "go-fuck-yourself"-level passive aggression, or mindless hopefulness that there might actually be a universe in which Github (or a company like it, with hundreds of millions of dollars of venture funding) could be open source. If I worked at Github, my first thought after reading this would be "mmmmm yeeeeaaaaaaa y'can g'fuck yr'self", while the second thought would be "yea, you're not wrong". Generally, passive aggression gets you nowhere when you're asking for something from someone/something who owes you nothing (I know, I know, they "owe" their customers everything).
The Node/React/JS community is hilariously entitled, petulant and childish. The tone of this whole letter is so god damned millennial, it's mind-boggling, because they're not wrong about anything they're asking for. But it's how they ask for it that leaves a dry, acid-y taste in your mouth.
> Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!
LOL. I can't tell if this is "go-fuck-yourself"-level passive aggression, or mindless hopefulness that there might actually be a universe in which Github (or a company like it, with hundreds of millions of dollars of venture funding) could be open source. If I worked at Github, my first thought after reading this would be "mmmmm yeeeeaaaaaaa y'can g'fuck yr'self", while the second thought would be "yea, you're not wrong". Generally, passive aggression gets you nowhere when you're asking for something from someone/something who owes you nothing (I know, I know, they "owe" their customers everything).
The Node/React/JS community is hilariously entitled, petulant and childish. The tone of this whole letter is so god damned millennial, it's mind-boggling, because they're not wrong about anything they're asking for. But it's how they ask for it that leaves a dry, acid-y taste in your mouth.
I agree that the "we’re very good at that!" was not needed. But the rest of the letter is ok to me, not particularly entitled. It is after all an open letter, open letters are designed to pressure people into something. In this case, these people have been asking for changes for years nicely and privately and have been ignored. They are just pressuring them as any customers would do. One may ignore the history of git, but its very existence came to be because a million dollar company called BitKeeper started ignoring its open source customers because they didn't owe them anything. Look what happened to them. Who even remembers BitKeeper? Maybe github should take these millennials hippy contributors more seriously if it doesn't want to end the same way.
https://en.wikipedia.org/wiki/Git_(software)#History
https://en.wikipedia.org/wiki/Git_(software)#History
Interestingly most of these people are older than the millennial category
Fooled me ;)
People often ask why WordPress doesn't use Github for its primary development (they do have official read-only mirrors there), and it's not just because they already had an SVN-based system in place when Github came to be. It's because the tooling they already had was more sophisticated, especially regarding issues.
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.
A proposal for a better way to deal with github issues: a discussion tab. https://github.com/dear-github/dear-github/issues/44
I'd settle for just a fix to the (minor) data-loss bug that I reported nearly a year ago, and which still crops up once a month or so.
That, and something for code review. Pull Requests are terrible for code review, and it wouldn't take that much to make them so much better.
That, and something for code review. Pull Requests are terrible for code review, and it wouldn't take that much to make them so much better.
I got frustrated waiting for improved PR code review, so I built https://reviewable.io. It's best suited for private repos (since there's a learning curve that make throw off potential open source contributors) but it addresses a lot of the issues with PRs. Take a look!
I've actually looked at Reviewable multiple times for use within our team, but never decided to use it. From my usage of the demo, it feels complicated. There are a lot of controls on the screen, and I struggle to tell what exactly I'm looking at at any given time.
I also tried the demo, and was shocked to see that Reviewable had edited our PR descriptions to include a big "Review on Reviewable" badge. We currently make heavy use of PR descriptions in quite specific formats, and it felt like Reviewable was forcing itself upon us.
To be clear, I'm really glad someone is looking at this problem, and Reviewable looks like a step in the right direction. I'm just quite opinionated on code review and developer tools, and I feel like it could be much better.
I also tried the demo, and was shocked to see that Reviewable had edited our PR descriptions to include a big "Review on Reviewable" badge. We currently make heavy use of PR descriptions in quite specific formats, and it felt like Reviewable was forcing itself upon us.
To be clear, I'm really glad someone is looking at this problem, and Reviewable looks like a step in the right direction. I'm just quite opinionated on code review and developer tools, and I feel like it could be much better.
Thanks for checking out Reviewable, and sorry it didn't work out for you. It's definitely a more complex tool than plain PRs but you also get a lot more functionality in return.
If you checked it out before I added the interactive onboarding (aka butterflies) and on-demand help you might want to try (yet) again, since I've been told it makes it a lot more approachable. Otherwise, and if you have the time, I'd love to sit down with you (virtually or otherwise) to do a short user study so I can better understand the UX pain points and maybe fix them.
As for the badge, it's actually mostly there to help developers find their way to the review. In public repos, it's also the marketing payment for the otherwise free service, but in private repos I can switch it off for you (the flag doesn't have a UI yet).
I'm always looking to improve Reviewable, but in the end it's unabashedly opinionated too, and sometimes those opinions will clash -- I'm OK with that. I'd rather make a tool that some people will love than an enterprise monster that everyone will love to hate. :)
If you checked it out before I added the interactive onboarding (aka butterflies) and on-demand help you might want to try (yet) again, since I've been told it makes it a lot more approachable. Otherwise, and if you have the time, I'd love to sit down with you (virtually or otherwise) to do a short user study so I can better understand the UX pain points and maybe fix them.
As for the badge, it's actually mostly there to help developers find their way to the review. In public repos, it's also the marketing payment for the otherwise free service, but in private repos I can switch it off for you (the flag doesn't have a UI yet).
I'm always looking to improve Reviewable, but in the end it's unabashedly opinionated too, and sometimes those opinions will clash -- I'm OK with that. I'd rather make a tool that some people will love than an enterprise monster that everyone will love to hate. :)
One annoying issue I found with github is that it doesn't provide a discussion board. a lot of times, I have a question to ask, it doesn't mean I found a bug or anything needs progress tracking, but I have to go through the "github issues".
To what degree a company has to not give a f$#% when maintainers of largest projects on a platform can't get any feedback (compounded by a fact that some of those maintainers are very prominent employees of largest github paying customers)
Being a maintainer on a project with some minor community on GitHub is such a garbage experience.
It’s pretty neat as a general user, but at least you get the impression with BitBucket that they prioritize productivity and project management. And the task system hasn't received any significant updates since their inception - which is a shame, because tasks are an awesome invention, they just have to be implemented awfully with issues.
I also remember that we recently had to move the entire decision-making process to Slack instead where I suggested we just use the emoji voting system to make our decisions with.
What really gets to me is how adamantly GitHub has ignored all the people who've gone on about this forever. Last time they seemed to care marginally was when jacobian finally managed to twist their arm and get them to implement the Close Issue feature, because one repo issue was a radioactive pit of abuse and invective.
It’s pretty neat as a general user, but at least you get the impression with BitBucket that they prioritize productivity and project management. And the task system hasn't received any significant updates since their inception - which is a shame, because tasks are an awesome invention, they just have to be implemented awfully with issues.
I also remember that we recently had to move the entire decision-making process to Slack instead where I suggested we just use the emoji voting system to make our decisions with.
What really gets to me is how adamantly GitHub has ignored all the people who've gone on about this forever. Last time they seemed to care marginally was when jacobian finally managed to twist their arm and get them to implement the Close Issue feature, because one repo issue was a radioactive pit of abuse and invective.
I wonder if the whole "managerless culture" is to blame and is unfixable? (In other words, why hasn't SOMEONE had this thought about issues in N years? One is they deem it not a problem, another could be that they think to optimize for the filer, and the maintainer doesn't matter, or... there's no organization at all?)
There could be (theoretically) no one to make anyone do anything, and perhaps the issue tracker is either a quagmire of a codebase or something no one wants to touch because something else is more exciting?
That's one theory.
My other theory is they spend a lot of time on scaling problems and/or GitHub enterprise (which I haven't seen) -- and don't really do features anymore.
But it does feel there is no vision for changes to GitHub (maybe they think it's "solved") and it's ceasing to evolve in noticeable ways in any direction.
Can't really be sure. But I find it interesting. Again, the core is good. It's just curious to watch it so closely and not see the needle moving in any perceptible way.
There could be (theoretically) no one to make anyone do anything, and perhaps the issue tracker is either a quagmire of a codebase or something no one wants to touch because something else is more exciting?
That's one theory.
My other theory is they spend a lot of time on scaling problems and/or GitHub enterprise (which I haven't seen) -- and don't really do features anymore.
But it does feel there is no vision for changes to GitHub (maybe they think it's "solved") and it's ceasing to evolve in noticeable ways in any direction.
Can't really be sure. But I find it interesting. Again, the core is good. It's just curious to watch it so closely and not see the needle moving in any perceptible way.
I like the theory of the flat-office culture or philosophy affecting this.
Then again, it could be the kind of anarchic Libertarian or laissez-faire bent that we see with reddit that makes it exceedingly different to grant special permissions and privileges, especially across subreddits/issues/users/orgs. Or maybe user experience just doesn't matter for today's start-ups; maybe we've passed the Overton window for start-ups deciding it's not worth caring about their users.
A lot of the time, I feel like more of a user+ than a(n) (super)admin on my own repos. I might as well have the permissions and tools to ruin my own project - in the name of pure unadulterated freedom if for no other reason.
The dashboard and notification system have always been POS, too, so it might just be that everything that basically isn't tethered to a GUI is on the bottom of the totem pole.
Then again, it could be the kind of anarchic Libertarian or laissez-faire bent that we see with reddit that makes it exceedingly different to grant special permissions and privileges, especially across subreddits/issues/users/orgs. Or maybe user experience just doesn't matter for today's start-ups; maybe we've passed the Overton window for start-ups deciding it's not worth caring about their users.
A lot of the time, I feel like more of a user+ than a(n) (super)admin on my own repos. I might as well have the permissions and tools to ruin my own project - in the name of pure unadulterated freedom if for no other reason.
The dashboard and notification system have always been POS, too, so it might just be that everything that basically isn't tethered to a GUI is on the bottom of the totem pole.
GitHub does certain things very well, other - not so much. I really think the best way to get them to focus is to start contributing massively to GitLab.
Anyway, implementing just voting won't be a such a good idea in the time of Emoji Reactions!
Anyway, implementing just voting won't be a such a good idea in the time of Emoji Reactions!
Actually, GitLab counts some emojis as votes - so you can have your :cake: and eat it too ;-)
- https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
- https://github.com/gitlabhq/gitlabhq/pull/5724
- https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
- https://github.com/gitlabhq/gitlabhq/pull/5724
Issue spam (in the literal sense) definitely needs addressed as well: https://pbs.twimg.com/media/CYI31g1UQAUXQbs.png
It's my project, why can't I just delete issues like any other bug tracker?
The issues were deleted in fairly short order, but their notifications were still sent out to all repository watchers and persisted beyond the issue deletion. Also, most issues were generated mere seconds apart from accounts less than a day old.
So the issue isn't that GitHub didn't let them clean up the issues after the fact, but that there were no a) rate limiting options, b) user reputation options, or c) issue submission filtering options.
Any one of those three would have reduced the impact significantly.
So the issue isn't that GitHub didn't let them clean up the issues after the fact, but that there were no a) rate limiting options, b) user reputation options, or c) issue submission filtering options.
Any one of those three would have reduced the impact significantly.
[deleted]
This resonated so much with me
PS, it was moved to https://github.com/dear-github/dear-github
PS, it was moved to https://github.com/dear-github/dear-github
Please update the link to https://github.com/dear-github/dear-github
Thanks, I've been trying all day to open the original link on mobile and it just brings my phone to its knees and never opens. Not even sure what is behind that link other than perhaps a very large Google doc?
Funny. It's like "Hi, you are rich. We like you. You should onate your money".
There are tradeoffs, so pick services you like.
There are tradeoffs, so pick services you like.
I guess I don't know how to use githib. You can send bug reports on a project. But how do you send questions or ask for advice?
Totally agree with what has been said. However, I find it interesting that most of the signatories displayed were for JS projects.
gog.com has a great mechanic for this which might work here called a community wishlist [1] where people can submit games whey wish to see and people can vote on it and eventually they get things done when possible.
[1]http://www.gog.com/wishlist
[1]http://www.gog.com/wishlist
I am interested in understanding how much recurring revenue Github is receiving for hosting these projects.
I've never seen any issues spammed with +1s like the TravisCI request for Bitbucket support
Can anyone post a précis/examples - apparently I do not have rights to see any spreadsheets at all.
we maybe need a feature of hotness of a bug, "affects me too", that'll prioritize issues out of a bucket load of issues, plus on github you first raise an issue then it is sorted into feature request or bug, can be made better
[deleted]
Classic JavaScripters reaction: throw more tooling at it
[deleted]
Url changed from https://docs.google.com/document/d/14X72QaDT9g6bnWr0lopDYida..., which points to this.
NB: Duplicate post: https://news.ycombinator.com/item?id=10904693
Since they're both near the top we might as well treat the later post (which is the other one) as the duplicate.
The post with ~110 points was killed in favor of the ~50 point post at the time. In that case using time as the tie breaker might not be the best since people will have to upvote again.
In general you're right, but this story was guaranteed not to lack for upvotes. Indeed it went to #1 as soon as we buried the other one as a dupe.
I realize it's not a big deal, and it's actually a great sign about the HN community that almost no one cares much about karma. But we do want to try harder to give the original submitter credit, because then the incentive is aligned with what's best for the community: finding good stories that haven't been posted yet.
I realize it's not a big deal, and it's actually a great sign about the HN community that almost no one cares much about karma. But we do want to try harder to give the original submitter credit, because then the incentive is aligned with what's best for the community: finding good stories that haven't been posted yet.
[deleted]
[deleted]
[deleted]
Chris Wanstrocity is an inept leader, social activists roam the halls in self glory about their contributions to the world while Kakul spends money on retreats and hires senior product people who have zero open source or dev ops experience. This company needs intensive care with new leadership asap or they will be doomed, Gitlab is salivating right now.
While I applaud the initiative, it's also a pretty strong indictment of the JavaScript / node.js community that there is not even a single non-male OSS maintainer on this list of important JS projects.
What is being done in the JS community by those who lead it to make progress on this and who is leading that charge? If the answer is "Nobody", why is that true?
What is being done in the JS community by those who lead it to make progress on this and who is leading that charge? If the answer is "Nobody", why is that true?
There is plenty being done in JS/node communities (plural! because there is more than one) at all levels. It just turns out that change doesn't happen over night.
Conferences already reverse discriminate by aiming for a gender balance in speakers (despite the submissions they chose from being very imbalanced). User groups have adopted CoCs to protect female and minority members. There are even female-only special interest groups. There's also this: https://github.com/nodejs/inclusivity
Besides, the list you're referring to is not an exhaustive list of important JS projects. It's a list of maintainers who have signed this open letter. What does their gender add to the conversation?
Inclusivity in programming comunities and JS/node in particular has drastically improved throughout the past decade. But structural changes take a long time to show results. The distribution you're seeing today represents what was being done in the past, not what is happening today.
Conferences already reverse discriminate by aiming for a gender balance in speakers (despite the submissions they chose from being very imbalanced). User groups have adopted CoCs to protect female and minority members. There are even female-only special interest groups. There's also this: https://github.com/nodejs/inclusivity
Besides, the list you're referring to is not an exhaustive list of important JS projects. It's a list of maintainers who have signed this open letter. What does their gender add to the conversation?
Inclusivity in programming comunities and JS/node in particular has drastically improved throughout the past decade. But structural changes take a long time to show results. The distribution you're seeing today represents what was being done in the past, not what is happening today.
Addendum: if all the non-males majoring in literary/communications/gender studies who complain about the lack of diversity in STEM would major in STEM, maybe they would no longer have anything to complain about. Whining isn't a science.
...pretty strong indictment...
This is like blaming the schools for poverty. Yes it would be wonderful if Node module maintainers were a perfectly representative blend of all the races, genders, religions, and orientations on Earth. The gap between that vision of Node and the one we have pales in comparison to the gap between that vision of Earth and the one we inhabit.
This is like blaming the schools for poverty. Yes it would be wonderful if Node module maintainers were a perfectly representative blend of all the races, genders, religions, and orientations on Earth. The gap between that vision of Node and the one we have pales in comparison to the gap between that vision of Earth and the one we inhabit.
You could open a pull request on the list itself.
Tell us, why does the gender matter in this debate? Sounds rather sexist to me.
[deleted]
Why did this get downvoted? Ugh.
Hmm what does this have to do a) with topic b) with node.js?
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 [email protected].