10 ms·

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 Commu

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 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 jono@github.com.

bnegreve 11y ago
There are more authors on the second page.
- jonobacon 11y ago
  Oops: I posted too quickly. Updated.
- pvorb 11y ago
  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).
  - simoncion 11y ago
    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.
    - jacalata 11y ago
      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'?
      - simoncion 11y ago
        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 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))
        pvorb 11y ago
        Yep, I've been looking at the Google doc. Basically I think it's just a bad way of publishing things online.
    - pvorb 11y ago
      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.
krschultz 11y ago
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-requests-for-trello http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144 https://github.com/isaacs/github/issues/144
- jbergstroem 11y ago
  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.
- grey-area 11y ago
  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.
  - jessaustin 11y ago
    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.
electic 11y ago
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.
- jonobacon 11y ago
  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.
  - yohann305 11y ago
    I'm glad to see someone from github is actually replying on HN and not ignoring this. Thumbs up
    - malexw 11y ago
      Not just anyone - Jono literally wrote the book on building developer communities: http://www.artofcommunityonline.org/ http://www.artofcommunityonline.org/
      - avinassh 11y ago
        It is also freely available as PDF - http://artofcommunityonline.org/Art_of_Community_Second_Edition.pdf http://artofcommunityonline.org/Art_of_Community_Second_Edit...
      - jonobacon 11y ago
jc123 11y ago
Perhaps Github Issues itself should be available as a mechanism for people to provide feedback about Github itself.
- derflatulator 11y ago
  Hypothetical link: github.com/github/github/issues
jhchen 11y ago
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.
- deckar01 11y ago
  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.
  - johannes1234321 11y ago
    You can't fully disable the issue tracker: Pull requests can't be disabled and each PR becomes an issue.
simonebrunozzi 11y ago
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.
dragonsh 11y ago
@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.
- Killswitch 11y ago
  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?
  - zanny 11y ago
    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.
the_mitsuhiko 11y ago
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.
- bsimpson 11y ago
  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.
vrv 11y ago
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 https://github.com/isaacs/github/issues/268
kevinSuttle 11y ago
Nice to meet you Jono. I maintain a similar list, albeit a bit more focused on GHE. https://github.com/kevinSuttle/github/issues https://github.com/kevinSuttle/github/issues
dfullarton 11y ago
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.
KuhlMensch 11y ago
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/18 * https://github.com/isaacs/github/issues/215 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 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! :'()
seivan 11y ago
Not sure you'll read this but I'd love a tagging feature for starring. Sorting on code isn't good enough.
- yAnonymous 11y ago
  +1
VeejayRampay 11y ago
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.
deleted 11y ago
[deleted]
oneJob 11y ago
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.
- eric_h 11y ago
  At least he responded, and promptly. Let's not jump to conclusions just yet.
- sethammons 11y ago
  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.

bnegreve 11y ago

There are more authors on the second page.

jonobacon 11y ago
Oops: I posted too quickly. Updated.
pvorb 11y ago
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).
- simoncion 11y ago
  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.
  - jacalata 11y ago
    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'?
    - simoncion 11y ago
      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 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))
      - pvorb 11y ago
        Yep, I've been looking at the Google doc. Basically I think it's just a bad way of publishing things online.
  - pvorb 11y ago
    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.

krschultz 11y ago

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-requests-for-trello http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144 https://github.com/isaacs/github/issues/144

jbergstroem 11y ago
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.
grey-area 11y ago
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.
- jessaustin 11y ago
  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.

electic 11y ago

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.

jonobacon 11y ago
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.
- yohann305 11y ago
  I'm glad to see someone from github is actually replying on HN and not ignoring this. Thumbs up
  - malexw 11y ago
    Not just anyone - Jono literally wrote the book on building developer communities: http://www.artofcommunityonline.org/ http://www.artofcommunityonline.org/
    - avinassh 11y ago
      It is also freely available as PDF - http://artofcommunityonline.org/Art_of_Community_Second_Edition.pdf http://artofcommunityonline.org/Art_of_Community_Second_Edit...
    - jonobacon 11y ago

jc123 11y ago

Perhaps Github Issues itself should be available as a mechanism for people to provide feedback about Github itself.

derflatulator 11y ago
Hypothetical link: github.com/github/github/issues

jhchen 11y ago

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.

deckar01 11y ago
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.
- johannes1234321 11y ago
  You can't fully disable the issue tracker: Pull requests can't be disabled and each PR becomes an issue.

simonebrunozzi 11y ago

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.

dragonsh 11y ago

@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.

Killswitch 11y ago
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?
- zanny 11y ago
  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.

the_mitsuhiko 11y ago

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.

bsimpson 11y ago
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.

vrv 11y ago

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 https://github.com/isaacs/github/issues/268

kevinSuttle 11y ago

Nice to meet you Jono. I maintain a similar list, albeit a bit more focused on GHE. https://github.com/kevinSuttle/github/issues https://github.com/kevinSuttle/github/issues

dfullarton 11y ago

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.

KuhlMensch 11y ago

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/18 * https://github.com/isaacs/github/issues/215 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 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! :'()

seivan 11y ago

Not sure you'll read this but I'd love a tagging feature for starring. Sorting on code isn't good enough.

yAnonymous 11y ago
+1

VeejayRampay 11y ago

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.

deleted 11y ago

[deleted]

oneJob 11y ago

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.

eric_h 11y ago
At least he responded, and promptly. Let's not jump to conclusions just yet.
sethammons 11y ago
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.