Hey I don't know if anyone has mentioned this here already but we (Charcoal) have been seeing really strange behavior from the API (posts taking like upwards of ten minutes before the API data is available and fetching them works). We haven't posted anything on Meta yet but I was wondering if this was something anyone was aware of and what the deal is
(Especially new) users often use redundant tags in the title redundantly. In fact, by far the most common edit reason I use a the moment is “removed tag from title”. There’s a consensus that tags don’t belong in the title (see Using tags in question titles) – common sense also dictates this: in g...
@quartata API master is @if.... (new awesome name of Normal Human :)) so he can probably tell. (well, not sure "master", but he's using it a lot for various things.)
It was tough to pin down until we saw it happen with manual reports because Smokey wouldn't notice if it didn't get every single post back it requested for in batch when scanning. It would just assume it was deleted and not try again
an implicit assumption, that is. we don't check how many items we get back is the point
@quartata I don't think this is something our SRE team is aware of. (I've been searching their chat.) If you put together a meta post documenting the problem, I'll make sure they see it.
I guess too many people/things are using the API so they added this caching, but I agree that's annoying. Perhaps they can give non-cached access for certain API keys?
@ShadowtheHedgehogWizard the wizard starts by telling a story like "I visited a fish store yesterday" and then shows a piece of paper with the words "Fresh fish sold here today" claiming that it is a replica of the shop banner/ads.
@Nick_Craver @_ArtOfCode Is that a new thing? We've been depending on post data being there after about 3 seconds; it's worked for the last three years.
@Nick_Craver @_ArtOfCode To clarify, do you know what happens in this series of events? (1) API request is made for post 12345, which doesn't exist, at 00:00:00. (2) Post 12345 is created at 00:00:01. (3) Another API request for post 12345 is made at 00:00:04. Should request 3 hit a cache?
No I know, I wrote that. But I was confused and thought it had deleted from an FP, not that the post itself had been deleted
@Undo Tinfoil hat alert: if this is really what's happening then someone could deliberately be querying for the next ID before posting spam to cache a miss
I can't think of any well behaved app that would query for an ID that didn't exist yet
If so that's genius and totally evades Smokey
Like even if no one is actually doing it it's still a potential attack if they cache like that
General rule: spammers are dumb. You can count on them to be dumb. Being intelligent takes time, which could be spent posting more spam. — ArtOfCodeFeb 20 '17 at 20:35
Related: Post data isn't available in the API until several minutes after post creation -- the same cache behavior is probably the (unintentional) cause of these bugs.
Steps to reproduce:
Predict the next post ID (since they're sequential, this is trivial on low-traffic sites.)
Query the non-e...
I haven't advocated unpinning accepted answers for a while, so I need to mention it again... pinning old accepts that are wrong is bad. They should at least float like self-accepts do.
So many downvotes after so many years should unpin it.
I like three downvotes after one year, personally.
@Undo Forgot to mention that DavidPostill posted another answer in the sandbox like a minute after I did the bug, I queried for it and it showed up, then queried for my answer again and it didn't show up
Anyways, when it comes to voting to delete (as a regular user), I weigh everything on the table. A bad answer that is pinned is an additional strike against it, IMHO.
Regarding the new API cache, think it's really a mistake... API should be instant otherwise it's pointless. People will switch to scrape the site, which will just overload the server/database even more.
Related: Post data isn't available in the API until several minutes after post creation -- the same cache behavior is probably the (unintentional) cause of these bugs.
Steps to reproduce:
Predict the next post ID (since they're sequential, this is trivial on low-traffic sites.)
Query the non-e...
@ShadowtheHedgehogWizard an accepted answer is only pinned if the question and the accepted answer are not posted by the same person. We can, and should, extend that logic.
if accepted.answerer == asker: # we have now.
accepted.unpin()
# we need this added...
elif accepted.downvotes >= 3 and accepted.date_accepted > one_year_ago:
accepted.unpin()
@quartata oh.. I see now. Smells strongly like a bug. Happened to me once actually. (on site I developed, caching empty responses which later broke things up.)
@AaronHall I think it might help if you went through a few examples and show that a) there really is a problem with old accepted answers and b) that your criteria is reliable. The first would be most helpful in terms of actually getting something implemented. We've gone around and around on this internally and in public and it's really hard to pin down (sorry) under what conditions the problem exists. Most of the time there's a highly upvoted comment or answer right under the pinned answer.
@JonEricson I'm not sure the incumbents in the community are willing to choose changing the policy of pinning accepted (non-self-)answers in perpetuity - especially since many of them wrote half-baked answers that got accepted (whether due to wit or a then-present lack of excellent alternatives). I think this is going to be a Joel decision.
If we want more downvoting - I think this will encourage more downvoting where it counts.
"you want me to downvote? give up my rep points to change the integer? That answer is accepted, it won't affect the sort order, so why should I do that?"
If I recall, it was Jeff who wrote the justification for pinning a long time ago. In my mind, and perhaps others - Joel is the only one who can overrule him.
Sure it's easier if we're all protesting for it dancing in the streets singing "thank you very much" but I do believe that's what it's going to come down to.
Well that's why I'm bugging you all from the Tavern every so often.
But if I convince the big cheese, decision is made. If I don't and he's staunchly against it, then it doesn't matter if everyone writes a google doc screed on the subject matter...
@Catija I'd be happy to get rid of pinning entirely. But there are just enough cases I've seen where the top voted answer just didn't help the asker. It's clearly not a perfect system, but it's nowhere near the top of things I think need fixing around here.
@JonEricson Eh... but accepting an answer on meta doesn't mean anything... Half of the time I see people on meta complaining about something, they accept the answer that validates what they feel, not what the community thinks... sure, it's probably heavily downvoted... but that just makes the user look even worse, which seems ... mean?
@JonEricson Sure. I have an answer on M&TV that has several times the votes of the accepted answer... which says, somewhere, "in addition to what Catija said...". :/
@AdamLear That does seem to miss the point of adulting. Paying the bills is child's play once you've learned how, but it's not fun. I wonder why the OP picked it. Cleverness?
@JonEricson Looks like it was accepted when it was still in the first revision: english.stackexchange.com/revisions/373831/1. Where it looked like a legit answer, albeit very wrong. But, if you're the person who doesn't know the answer, it looks plausible. And if you did know, you wouldn't be asking.
@Shog9 ... Eh... unless Staff or (on a per-site meta) a Mod answers the question (in an official capacity), I'm pretty much in the camp that accepts on meta don't really do anything of value.
@AdamLear I'd be careful of that... if you're talking about a site where the answer relates to software, lots of edits could be because the OP is being really good about updating their answer to reflect the current standards, keeping it up-to-date.
Though, since I don't use any of those sorts of sites, I'm not actually sure how often that occurs... how much users maintain answers that are likely to go out of date.
I doubt we could ever have a definitive, 100% correct (especially across sites) set of criteria that points to a bad accept. But surfacing potential problem cases as a combo of things (edits, downvotes, etc) may be possible. I'm with Jon, though - there are bigger problems.
I think the best solution is to just delete very wrong answers that happen to be accepted. That said, I'd be shocked if anyone is fooled by the checkmark when the answer is -77 and greyed out.
@Catija if you're looking at the author to determine correctness, then accept doesn't mean anything to you then either...
...but in objective terms, accept has a very concrete and well-defined meaning: the author of the question clicked the checkmark.
It never means anything else.
There's no squishy definition of "correct" or "best", there's no override for other people to sometimes trigger an accept... It always and only means that one thing.
@Shog9 I understand accepts. I find them of some value on main sites... I'm more than happy to repeat until I'm blue "It's what the author decided to do/was the best solution/was right for them"... I just don't see the value on meta.
they don't get the attention of flashy [feature-requests] or meaty [discussions], but [support] questions are an important part of meta.
If I ask, "how do I unaccept an answer?" and someone replies "click the green checkmark next to the answer you previously accepted", and I try it and it works... I don't need a dev to come by and post another answer, I can go away happy. Or accept the answer and then go away happy.
When SO launched, there was essentially no documentation... So folks asked tons of questions like that on Stack Overflow. A bit part of why meta exists is to house them.
On Stack Overflow, the "accepted" answer shows that the loop has been closed and the question has been answered to the satisfaction of the asker. That's true here too. But there's a big difference between accepting an answer on a practical and specific question as opposed to a general and broad...
@Shog9 because the majority of support questions nowadays are either "halp, a moderator treated me unfairly in this case" or "halp, the audit system banned me unfairly yet again"
Might be a case where Channels can help us get a clearer picture. I can see where a question might be about ongoing development and the accepted answer works today, but won't in a few months time. Plus the asker might leave the company and nobody can fix the question. (But then again, there might be more incentive to just edit the accepted answer. ;-)
@JonEricson Do you think accepts would even work the same way on a channel? Considering those issues alone, I would think that it would make sense for the admins to the channel (staff of the group who own it) be able to change accepts so that they can maintain documentation of how it used to work.
If these answers are supposed to be some sort of documentation of solutions for an internal team, I would think that accepts should reflect the correct answer, not necessarily the one that specific staff member likes the best.
the whole value of Channels to folks is that they already know how SO works - ideally we change only those things that are necessary to allow channels to work similarly well
What bluefeet said above is ... kinda the big issue. Internally, we've spent an insane amount of time on this, on at least 3 separate occasions, and have exactly nothing to show for it.
@Shog9 I was under the impression that Channels was a great way for the devs at SO to figure out how to make SO better... more useful... seems like the perfect place to test whether there should be changes made to how things like accepts work.
@Catija making accept ambiguous isn't a clear win though. As soon as it stops meaning one precise thing, there's no good reason for it to exist at all. Make voting available at 1 rep and there's no need for it.
I've told this story before but... Go look at the MSDN forums if you want to learn why mod/community/admin overrides for Accept are a bad idea. Endless questions with a bullshit answer "accepted" by an admin so that they could be closed.
Q: "I read the docs for X, and followed the example there *to the letter*, but I'm getting error code Y - any idea why?" A: "Please read the docs for X - you'll find an example there that should help you" *accepted by admin*
@Shog9 I disagree. If voting drops off in a channel because the users don't really care about voting at all, newer answers that update the information in a question won't ever rise to the top. The point Jon made about the staff member who asked the question leaving is a valid one... I see value in a question containing multiple answers that reflect the history of the problem... sort of like the monthly updates list... Joe can accept the new month every month so that it's at the top...
but if he quits, someone else is updating the question and there's no way to keep the most recent answer current.
@ShadowtheHedgehogWizard I spent months querying data, coming up with possible solutions to the problem only to have it thrown out because it's not a large enough problem to spend time on
@Catija if folks aren't voting, or folks aren't voting on answers to that question because no one needs the question anymore... Then sticking an admin with the job of bit-twiddling on it is a waste of their time (and likely won't happen).
@Shog9 Maybe I'm jaded because I rarely vote but... I guess I have a difficult time seeing small groups of people feeling the need to vote when there's little incentive. If questions only get one answer and it's always the "official" or "correct" answer, what does upvoting it benefit? Perhaps my assumption that channels doesn't require users to meet rep levels is incorrect?
I'd be interested in seeing how an enterprise system looks.
@Catija what's the motivation to answer? What's the motivation to even ask? Why not just interrupt your co-workers and badger them one-on-one like you were already doing?
Data that burns with blue flame... that's something I'd like to see. :D
But hey, @Jon also spent tons of time on things that never came to life... probably @Shog too. That's a risk one got to consider before spending time on something. No? :)
@Shog9 I don't ask many questions on SE (outside of meta)... so I'm not sure that I'm the right person to ask that of. Presumably there's benefits for companies spread around the world where you can't just go and bug your coworker... I've always been more interested in answering because I like sharing what I know to help people...
@Catija answering is by far the most enjoyable way to spend time on these sites. But folks still ask questions, and in great numbers, even when we try our best to discourage them - why?
and when someone saves you days of setbacks in your job - that you do to make money so that your family has food and a place to live - you're hopefully motivated to express gratitude in some small way, yeah?
So, you upvote. Or accept. Or both. Or neither and just write "+1 thank you so much!!!!!!!".
Maybe it's normal on SO... but posts only getting 1-2 votes seems like something that would be difficult to adjust to... That's why I was saying it'd be interesting to see it in action to see how people vote, though my guess is that it will depend greatly on the group using it, much as different network sites attract different voting styles.
@Catija personally I think there should be much bigger incentive to vote when it's for small groups, e.g. more badges, or even rep gain just for voting.
+5 rep at the end of every day where you voted on a post that was also voted by someone else, not closed (in case of a question), and not deleted.
Sounds crazy for SE, but for Channels... might be a needed incentive.
Eh... I think that part of any system is some way to encourage people to use it... we have three wikis at my work and I'm pretty sure that the only people who use them are our documentation team... they're useless because people forget they exist.
@ShadowtheHedgehogWizard Eh... Wikis are answers... If I want to tell someone how to configure their voicemail, I just write an article about it... Q&A requires them to first ask "How do I configure my VM?"
... and be clear that they mean voicemail and not their Windows 98 virtual machine.
@balpha why Winter Bash this year had no real secret hats? The only hat that was almost not easy to figure was Mother of Dragons... all the rest... well, no need to say the obvious. Wonder if it was deliberate decision, or just lack of time to think of smart secret hats, like there used to be all the years? (one of my favorites was Onion Knight, people spent hours trying to figure how it was gained.) /cc @Derpy
@Catija well, but after those 72 hours it became trivial. Onion Knight hunt lasted during the whole event, I think.
There was also a secret hat for posting a question that was shared x number of times, think it was the hardest one to gain/guess ever, can't find it now. :/
I guessed that hat was related to HNQ, but turned out to be wrong eventually.
@Stijn just noticed your question hit HNQ, kudos! :D
(think you can safely ask your second question there now.... ;))
I can see that some people were arguing about accepts. Note that I'm not suggesting changing accepts. Just the pinning. We should unpin the accept after a period of time and downvotes. There's no sense in keeping answers the community dislikes pinned to the top. It just makes voting seem futile.
I think that it's slightly confusing that sorting by "votes" is the one sort that weights the accept at the top... particularly when it's not the highest-voted answer.
We don't want a bunch of one-offs to "deprecate". We need to automate. The way to do that is: 1) Unpin the accepted answer after 1 year, and 2) value more recent votes more than much older votes.
Related: Post data isn't available in the API until several minutes after post creation -- the same cache behavior is probably the (unintentional) cause of these bugs.
Steps to reproduce:
Predict the next post ID (since they're sequential, this is trivial on low-traffic sites.)
Query the non-e...
On Stack Overflow, the "accepted" answer shows that the loop has been closed and the question has been answered to the satisfaction of the asker. That's true here too. But there's a big difference between accepting an answer on a practical and specific question as opposed to a general and broad...
