Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
isaacs opened this Issue Jun 4, 2013 · 131 comments

Comments

Projects
None yet
@isaacs
Copy link
Owner

isaacs commented Jun 4, 2013

Just what the title says.

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

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

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

@tekkub

This comment has been minimized.

Copy link

tekkub commented Jun 15, 2013

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

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

Love and octocats,
--tek

@isaacs

This comment has been minimized.

Copy link
Owner Author

isaacs commented Jun 17, 2013

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

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

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

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

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

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

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

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

@tjfontaine

This comment has been minimized.

Copy link
Collaborator

tjfontaine commented Jun 17, 2013

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

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

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 4, 2013

Sent the following to support@github.com:

Greetings,

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

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

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

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

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

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

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

chad


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

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 4, 2013

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

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 5, 2013

Response from @nuclearsandwich:

Hi Chad,

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

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

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

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

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

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

Cheers,
Steven!

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 5, 2013

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

Chad,

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

Cheers,
Steven!

@isaacs

This comment has been minimized.

Copy link
Owner Author

isaacs commented Jul 6, 2013

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

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

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

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

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

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

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

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

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

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 6, 2013

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

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

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

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 6, 2013

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 6, 2013

No go on @thechangelog.

@adamstac

This comment has been minimized.

Copy link

adamstac commented Jul 6, 2013

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

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

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

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


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

Sent from Mobile

@chadwhitacre

This comment has been minimized.

Copy link
Collaborator

chadwhitacre commented Jul 6, 2013

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

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

@adamstac

This comment has been minimized.

Copy link

adamstac commented Jul 6, 2013

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

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

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

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


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

Sent from Mobile

@tjfontaine

This comment has been minimized.

Copy link
Collaborator

tjfontaine commented Jul 6, 2013

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

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

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

@Utumno

This comment has been minimized.

Copy link

Utumno commented Oct 13, 2013

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

@patcon

This comment has been minimized.

Copy link

patcon commented Oct 13, 2013

👍

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

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

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

@chevex

This comment has been minimized.

Copy link

chevex commented Nov 12, 2013

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

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

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

@rlidwka

This comment has been minimized.

Copy link

rlidwka commented Dec 8, 2013

github

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

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

ps: +1 to this issue of course

@juniorplenty

This comment has been minimized.

Copy link

juniorplenty commented Jun 23, 2014

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

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

@foxbunny

This comment has been minimized.

Copy link

foxbunny commented Sep 16, 2014

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

@reedstrm

This comment has been minimized.

Copy link

reedstrm commented Oct 8, 2014

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

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

Their at 5 million users, BTW.

@stuartpb

This comment has been minimized.

Copy link

stuartpb commented Oct 23, 2014

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

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

@AnneTheAgile

This comment has been minimized.

Copy link

AnneTheAgile commented Nov 20, 2014

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

@stuartpb

This comment has been minimized.

Copy link

stuartpb commented Nov 21, 2014

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

@AnneTheAgile

This comment has been minimized.

Copy link

AnneTheAgile commented Nov 21, 2014

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

@360disrupt

This comment has been minimized.

Copy link

360disrupt commented Oct 1, 2018

If a project is abandoned and licensed open source it should be able to be claimed by the community. E.g. last commit > x days + x people voted with a button "this repo has been abandoned" should open up a function to claim this repository as the new maintainer/or make a fork the main fork. Otherwise, everybody forks it to solve their most important issues but the project loses its centralized place and dies.

@jacobgasser

This comment has been minimized.

Copy link

jacobgasser commented Oct 2, 2018

I think, there should be a way to be able to mark something as a password in the code, so that you don't need to change it, then push it. It would be so much easier if we could just push it, and not have to worry about people seeing a password.

@TPS

This comment has been minimized.

Copy link
Collaborator

TPS commented Oct 3, 2018

@jacobgasser That already exists. Else, you defeat the whole point of open source!

@crooksey

This comment has been minimized.

Copy link

crooksey commented Oct 18, 2018

It would be good if each project had a 'testimonials sections' . E.g users could publicly thank the author, I use so many projects that it would be great if you could leave a small (200 characters or something) comment on a projects page, letting the author know the projects great and how its helped etc. I would assume the default would be to not automatically publish these, but the repo owner could choose what comments to show/hide on their page.

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Oct 18, 2018

@aking1012 @mtschoen-unity @360disrupt @jacobgasser @crooksey Your ideas are very welcome, but not in this particular issue!

This issue is specifically for addressing the fact that GitHub does not provide a good public issue tracker for tracking issues with GitHub. It is not a general dumping ground for any ideas about how GitHub could be made better, so please don't use it for that, as that will cause a lot of confusion and inefficient discussion.

Instead you are welcome to submit a separate issue for each idea bug report via https://github.com/isaacs/github/issues/new - but before submitting, please search the issue tracker to make sure someone hasn't already submitted an issue for the same thing.

Thanks in advance for helping to keep this issue tracker well structured, with each issue focused cleanly on a single problem!

@strugee

This comment has been minimized.

Copy link

strugee commented Oct 18, 2018

And if you do submit a new issue, be sure to contact GitHub Support with it too! They don't monitor this repository.

@happyhuman

This comment has been minimized.

Copy link

happyhuman commented Nov 2, 2018

It will be great to be able to create private branches in a public repo. It really helps simplify a lot of situations where you are working on a feature that you are not yet ready to share publicly.

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Nov 2, 2018

@happyhuman This is the wrong place to submit such ideas, even if they are good ones. Please read the two comments immediately above yours.

Perhaps this issue could be locked and limited to collaborators, in order to prevent further off-topic comments.

@edjroot

This comment has been minimized.

Copy link

edjroot commented Nov 9, 2018

I'm surprised so few people are aware of Project Paper Cuts:

Project Paper Cuts is dedicated to working directly with the community to fix small to medium-sized workflow problems, iterate on UI/UX, and find other ways to make the quick improvements that matter most.

GitHub has always had feedback channels that influenced our product, though we aim to be more open and transparent with this work. We’re not only listening to email, sales, support, and Twitter. We’re also looking at the wider GitHub community’s creation of self-organized ‘feature request’ repositories and browser extensions, as well as actively asking for feedback about the small things that irritate you the most.

Doesn't this announcement pretty much settle a big part of this discussion? Shouldn't this be at least mentioned in the README?

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Nov 9, 2018

@edjroot commented on 9 Nov 2018, 19:11 GMT:

I'm surprised so few people are aware of Project Paper Cuts:

Project Paper Cuts is dedicated to working directly with the community to fix small to medium-sized workflow problems, iterate on UI/UX, and find other ways to make the quick improvements that matter most.

I'm not sure how many people are aware, but it has been mentioned on several issues in this repo.

GitHub has always had feedback channels that influenced our product, though we aim to be more open and transparent with this work. We’re not only listening to email, sales, support, and Twitter. We’re also looking at the wider GitHub community’s creation of self-organized ‘feature request’ repositories and browser extensions, as well as actively asking for feedback about the small things that irritate you the most.

Doesn't this announcement pretty much settle a big part of this discussion?

Maybe - it depends on exactly which discussion thread you are referring to. But it certainly doesn't resolve this issue - that won't happen until GitHub actually start an official, open equivalent to this issue tracker.

Shouldn't this be at least mentioned in the README?

Sounds like a good idea to me.

@vbjay

This comment has been minimized.

Copy link

vbjay commented Jan 22, 2019

Add Markdown polls. Allow md to specify max number of choices and priority of options. User picks option 1 and 3. Option 1 is set to first priority. Option3, to second priority. Link it by user so user can alter their votes from anywhere till the poll closes.

Have a polls page in a repo that shows current polls and a summary of the results. Let user drill down into a poll to see details of that poll.

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Jan 22, 2019

@vbjay Please read my previous comment.

@vbjay

This comment has been minimized.

Copy link

vbjay commented Feb 20, 2019

Then change the title of the issue.

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Feb 20, 2019

Yes I only just realised that the ambiguous title is why people keep getting confused and submitting ideas here. Unfortunately I don't have permissions to change it. @cirosantilli can you ditch everything up to and including the "a.k.a."?

@cirosantilli cirosantilli changed the title Public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary) Create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary) Feb 20, 2019

@cirosantilli

This comment has been minimized.

Copy link
Collaborator

cirosantilli commented Feb 20, 2019

@aspiers updated title to remove ambiguity.

@vbjay

This comment has been minimized.

Copy link

vbjay commented Feb 20, 2019

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

You really don't see the problem?

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Feb 20, 2019

@cirosantilli commented on February 20, 2019 12:20 PM:

@aspiers updated title to remove ambiguity.

Thanks a lot but I think this is still slightly ambiguous, as demonstrated by this comment:

@vbjay commented on February 20, 2019 12:25 PM:

You really don't see the problem?

@vbjay This is not about issues vs. feature requests. It's about the need for GitHub themselves to obsolete this repository. Did you read https://github.com/isaacs/github/blob/master/README.md or https://github.com/isaacs/github/blob/master/CONTRIBUTING.md before commenting?

@vbjay

This comment has been minimized.

Copy link

vbjay commented Feb 20, 2019

I know. My point is you seem to not understand what the issue title says. I'm sorry. Issues AND FEATURE REQUESTS Gee. Did you think of maybe something like

Convince github to open up their feature requests.

I decided to use a "public place to post and discuss issues and feature requests" and you decided to piss on it. So that shows on you. Not me.

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Feb 20, 2019

@vbjay I didn't piss on anything. In fact this is what I did:

  • politely pointed out your mistake
  • acknowledged the source of the confusion (since you are at least the 6th person to fall into this trap, so there was no need to feel sore about it)
  • worked with an admin to try to get it fixed
  • (again politely) explained why the fact that the title mentions feature requests still does not mean that this particular issue is the place to put new feature requests.

I have no idea why you are suddenly becoming uncivil but it's totally unnecessary. Noone is attacking you for making a minor mistake which was very understandable given the ambiguity of the issue title. You can continue ranting if you want but you won't receive any further replies from me.

@lantz

This comment has been minimized.

Copy link

lantz commented Feb 21, 2019

Clarification is preferable to having ongoing confusion and correcting people.

I would probably also prefer changing the title to something like "Convince github to create or authorize a public place to post and discuss issues and feature requests for github.com" simply because it emphasizes the challenging/impossible part: getting github/microsoft to change its ways.

You could lock this issue of course, but I hate it when people do that - it feels so hostile, and you have little recourse except to file another issue.

@aspiers

This comment has been minimized.

Copy link
Collaborator

aspiers commented Feb 21, 2019

@lantz Totally agree! @cirosantilli I fear people will continue to miss the "Create an" prefix - any chance of adopting @lantz's wording?

@cirosantilli cirosantilli changed the title Create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary) Convince github to create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary) Feb 21, 2019

@cirosantilli

This comment has been minimized.

Copy link
Collaborator

cirosantilli commented Feb 21, 2019

title updated again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.