151–160 of 491 posts
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.
Hi Adam, Addy, Andreas, Ariya, Forbes, James, Henry, John-David, Juriy , Ken, Nicholas, Pascal, Sam, Sindre, 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 pa…
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.
Don’t make it so easy to submit bad PRs
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 projects in terms of the problems mentioned in the document. For example, there is a strong correlation between +1'ers and JS…
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.
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'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…
> 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?
Earlier quoted context omitted.
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 informati…
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.
Earlier quoted context omitted.
> 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 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".
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:
https://github.com/detroitwaterproject/detroit-water-project
I was merely curious about how this fits into their grander strategy.
Earlier quoted context omitted.
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.
I'm glad to see someone from github is actually replying on HN and not ignoring this. Thumbs up
Don’t make it so easy to submit bad PRs I recurrently refer to this[0] PR, and the subsequent discussion, as the reason why, if any project of mine gets any bigger - it will not be accepting Github pull requests. [0] https://github.com/technion/maia_mailguard/pull/42
> uh oh, someone is still sulking [...] We really don't care about the drama
Oh, okay buddy.
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…
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.