What?? Is this a bug? I just saw one post in metasmoke review, and reviewed it. Still it shows 1 in review, but there isn't actually a review. i.stack.imgur.com/y2YM3.png (cc @Undo @ArtOfCode)
@AshishAhujaツ On StackOverflow, the orange number dictating the number of suggested edits in the queue also won't update when you review them. But at the other side, it can be easily implemented with javascript
In my TV there are modes. If you're on the cable mode, it won't happen like that, but if you're on the satellite mode, and the connection gets cut, it becomes.
The user that wrote this answer asked a completly clueless meta question about the rep cap (meta.stackoverflow.com/questions/326289/…). Together with his more then fishy rep history (including 14 reversed votes yesterday) I think that they're engaging in some fishy business. Maybe a mod can investigate and talk to them. – Magisch 7 mins ago helpful
I looked at the timestamps of the votes, and clicked through the users of the accepts. They all seem to be from around his area, some from some obscure college there. I also checked on the past history, he only recently started gaining rep this fast. Ontop of that he had a -140 reversal yesterday. So I concluded that a modflag was appropiate
TDD is nice looking, but also pretty painful. At work, I have a self-policy of trying for at least 70% code coverage on the controllers I add for each PR
code coverage is pretty cool, it shows you how much of your code you cover with your tests, which logic branches you hit the most, which ones are ignored
So many bugs in this project... turns out that not only could users mark each other's notifications as read, but regular users could also access moderator functions...
I am. But, I'm being picky about it. I am tired of driving into the office daily and really want something remote. I'd also like something more product management (or community management) orientated than straight technical programming related. I won't turn one down if I find one that looks awesome, but it's not my first choice.
I interviewed for a Manager of their Enterprise support team back in Feb.
Unfortunately for me (perhaps both sides), they are building that team from scratch and I didn't realize that. My experience is not building a support team from nothing - which means building out the phone support system, on site resources, etc. I can and have managed one that was operational though. They reposted the job in April and added a sentence about that requirement, so I'm guessing I'm not the only one that didn't realize it at the time
Despite that, the interviewer, HR and other people I talked to were incredibly helpful and able to answer any question I had. They know what they are doing and are growing fast
@Undo Heh. No, different team. Support for businesses that purchase Github enterprise
@Andy It's -2... anyway, I believe the point is that since a user id can be any positive number, the only way to do error checking is with negative numbers.
I'm still not so sure about individual functions. If nothing is factored out, the code ends up being so much longer and all you did is change an if statement into a function...
if content_lower.startswith("!!/COMMAND") ... :
# Multiple
# Lines
# of Logic
# Here
# with various
# levels
# of
# indention
# to
# mess with
# your
# head
vs
if content_lower.startswith("!!/block") ... :
command_execute(**parameters)
All of that indention can be pulled out of the main function and you can easily see what each command is doing
Multiple functions also allows refactoring to make them call each other, you can make k call !!/addblu, then if we want to add "user had been blacklisted" broadcast messages we need to only edit 1 place
@Andy But it's not too useful to test the individual function. I've broken the whole system before -- all of our tests test that if a chat message goes in, it comes out correctly.
@hichris123 sure, but I had rejected another request earlier this week so I had to come up with a sigh rule that is fair... he just didn't make it, close, but not close enough
It would be 2 or 3 weeks so let's say that @ArtOfCode is from the future and went ahead ...
So a thought on the ignoring system (cc @Undo because you've seen the code). Currently, if we have an ignored user, every feedback they create is marked ignored. If another feedback on the same comes along from someone who isn't ignored and the feedback type is the same, the ignored feedback is taken off ignore.
That's all fine and dandy.
The result of that, however, is to vet their feedback for them until they're not ignored any more. But they'll eventually get out of ignore, because only valid feedbacks can be added. Even if only one in a hundred is valid, they'll get out of it, and then they'll have full privileges again. When those get invalidated, they'll get ignored again, and we cycle round again.
So how would it be, when another feedback came along on the same post as an ignored feedback, and it isn't the same type, we take the ignored feedback off ignore but invalidate it?
We've got someone on ignore right now, actually. He's posted a few valid feedbacks that have been confirmed, so his valid total has gone up (progress towards unignore), but he's also posted a few invalid, and his invalid total hasn't gone up.
If we noted the invalid ones as well as the valid, that might paint a better picture.
@soup No, just count it for the checks. There'd be a path to recovery; people confirming your feedback would unignore it - making it count as valid in the checks
But in-between feedback (n) makes that a little iffy.
That'd be a lot of invalid feedback just because you're ignored. It might not be invalid, we just want someone else to review your feedback for now until you show you understand the system; marking everything new as invalid would make it incredibly hard to recover.
@ArtOfCode I'm still not following that, it'd always end up being either valid or invalid. The main difference between start-as-invalidated and invalidate-on-conflict is that the former would hurt you for not being the first feedbacker
Wow that's a long sentence
I do think that invalidate-on-conflict is the best route, though
presume-bad v. presume-good. Presume-good would work just fine here.
Oh, I see how you're thinking. Every ignored feedback will be reviewed eventually, so it doesn't matter which way we start because the end result will be the same. Yes, gotcha.
but yea, invalidate on conflict
not least for the stats... Starting invalidated would make an ignored users stats look terrible until the feedback got reviewed.
