How to know when a post is unhidden?

How to know when a post is unhidden?

I joined the GitHub Support Community forum recently and posted 2 questions. I immediately got 2 automated emails like:

Our automated spam filter, Akismet, has temporarily hidden your post in How to forward an issue to myself as email? for review.

A staff member (link deleted, see below --Fred) will review your post soon, and it should appear shortly.

We apologize for the inconvenience.

I clicked on the links and was unable to see my posts.

I assumed I’d get more automated emails when they were reviewed and approved. In an ideal world, the staff member reviewing them would have time to also post a reply.

3 days later, I’ve received no further emails. I clicked the links again, and can now see my posts. But I don’t know if others can see them, and there have been no replies.

I went to the URLs of the posts with another browser, where I was not logged in to the GitHub Support Community forum. So, that should be the same as anyone else trying to view the posts, I think. I can see them then also. Does that mean they are now fully visible?

Is anyone likely to see and respond to them? Or are they likely to go unnoticed since they’re now 3 days old and have dropped further down any list that’s shown in date order?

I’m assuming that the hide/review process was only because I was a brand new member, and won’t be done to every post I make. Perhaps I should repost the 2 questions, so they’ll appear more quickly at the top of any list of new posts? Or is that considered rude?

BTW, I had to delete the links in the quoted email above because I got a message saying:

Sorry, new users can only put 2 links in a post.

Thanks,
–Fred

Correct. If you can see them when logged out, they are visible.

We go through flagged posts almost every day other than weekends. It is unlikely that a post will remain hidden more than a day unless it is a weekend when our volumes in the forum is lower. So your post might be a little lower in the viewing, but it shouldn’t drop that far.

We also have a team looking for posts that don’t have any responses on questions about GitHub and GitHub products. While we don’t get to every questions by any means, we are actively looking to make sure that questions don’t fall through the cracks. We are also still working on ways to improve this process.

That will have something to do with how the spam filter looks at your posts. But it may also be the content of your posts as well. Since I didn’t process these posts, I am unable to tell you definitively why your posts got flagged by the automated system.

Please don’t repost questions. Creating duplicate topics and bumping your own posts goes against the community guidelines. However, I don’t want you to feel stuck in this situation either. If you would share links to your two posts without responses, I will take a look myself.

Honestly, I did not realize that emails weren’t sent out for when responses were unhidden. I made a similar assumption that you did and will ask internally about this to see if we can make that change if that isn’t already a feature.

I do agree that in an ideal world, staff resolving these spam flags would have time to respond as well. However, just to be transparent, we separate these tasks for a couple of reasons. Firstly, we want to get through the moderation queue as quickly as possible to allow us to unhide posts that shouldn’t be hidden and allow the community to see them quicker.

Answering questions can take some time, especially when switching from one type of cognitive task to another, so we try to minimize that sort of context switching. We also have different people who specialize in different questions because of the sheer size of the GitHub product makes it hard to be an expert in all areas. Because of this, the person that releases the flag on a post might not be the person capable of giving you a response.


I appreciate you taking the time to write to us about your experience. I will write in to see what we can do about getting automated emails sent out when a post is released. I’m not sure what that will take to accomplish, but I think that’s a good idea to improve the user experience.

1 Like

OK.  Thanks!

OK.  Yeah, they only dropped down a few dozen entries.  I’m not sure how far that is effectively.  Depends on the process used by you and others who might see and answer my questions.  They HAVE dropped “below the fold” so to speak.

Perfect!  I’ve been a programmer for 35+ years, and often have to monitor a ticket system to support users.  So, I understand how hard it can be to keep up with the large volume of questions and the wide range of user expertise.

Where’s the best place to post suggestions about this GitHub Community Support forum, as opposed to GitHub itself?  I posted this ticket to category:

  • “How to use Git and GitHub”

Later, I noticed there’s another category:

  • “Welcome and Announcements”

Its description says

  • “…or ask questions about the GitHub Support Community itself”.

Should I post suggestions there?  Or is there a separate bug/feature tracking system that I should use?  I have some ideas already and would be happy to post them.

As I said, I’ve used a LOT of version control systems over the years (VAX CMS, Unix sccs, Unix rcs, MS VSS, PVCS, CVS, and then finally Git).  And a dozen or more ticket tracking systems.

Here’s a tip I wrote a while back about the advantages of Git and some shell aliases I use for common Git commands:

  • xhttp://bristle.com/Tips/Programming.htm#git

(Delete the “x” from the "xhttp: above to use the link. I got an error when I tried to post with a link to my site, saying “Sorry you cannot post a link to that host.”

OK.

Yeah, I thought it might.  That’s why I asked first.  Thanks!

OK.  Here ya go:

OK.  Thanks!  I’ll be glad to submit a ticket to your tracking system, if any.  Or post them to this forum as separate posts.  Then I’ll get email notifications when the feature is added, rejected, or commented on.  Let me know where to post it.

I understand perfectly.  Been there, many times…

Exactly!  I once warned a manager that context switches were expensive.  Especially for a programmer, who’s holding a bunch of things in his head all at once, and can’t let any of them slip away without writing them down to be dealt with later.

Things that get forgotten due to an interruption or other context switch may eventually show up as bugs.  Also, at the start of each new context, you have to load a bunch of things into your head to remember how it all works, before you can start making changes.

I estimated that each context switch cost the company about 4 hours of programmer time, perhaps much more.  See the articles at the “Holding a Program in Your Head” row of my links page:

  • xhttp://bristle.com/~fred/#holding_a_program_in_your_head

(Delete the “x” from the "xhttp: above to use the link. I got an error when I tried to post with a link to my site, saying “Sorry you cannot post a link to that host.”

With titles like:

  • Why programmers work at night
  • Holding a program in your head
  • Programmer interrupted
  • etc.

Makes sense.

As a programmer, I’m guessing it won’t be too hard.  You already have a trigger that sends the “blocked” email when a new user posts something.  The automatic sending of “unblocked” email should be very similar.  Build it into the button or process that the reviewer clicks or uses to unblock the post.

But, of course, there may be more important new features on the wish list, and there are limited developer resources to do them all.

Absolutely!  Make things as pleasant as possible for GitHub users, especially new users.  If they get frustrated, they’ll all go to Bitbucket or GitLab.

–Fred

Honestly, the best way to get our attention about something in the forum is by using the Feedback button on the right hand side. We don’t have a category that is dedicated to the forum itself at this time.

Welcome and Announcements would also work.

Thanks for sharing. I’ll take a look right now.

Yeah, the technical issue probably isn’t that hard in of itself. However, we’re using a platform that is not home-brewed so beyond the specific technical limitations, we also are limited by the platform’s decisions and priorities. We’re talking with them now to find out what our options are.

1 Like