IP address reveals a number of related domains 14 139.59.91.71 2 prestigeprimrosehills.gen.in 1 prestigeelysian.in 4 prestigesmartcity.info 2 brigadeutopia.org.in 5 prestigefinsburypark.gen.in
@Makyen That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
@Makyen Since the recent issues with the API responses started, I haven't been able to use FIRE at all. I get a TypeError when the script tries to set the site variable. I noticed that you've been still doing reviews from FIRE. Did you do anything, or am I the only one with this issue?
@tripleee There have been issues with the SE API for many hours. They are definitely not resolved yet. Please see this meta for a bit more information, but it merely describes the issue. I haven't seen anything from SE commenting on the problems.
@Das_Geek I use a heavily modified version of FIRE. While it does have some issues under the current operating conditions, one of the things I've been working on for it is the ability to continue operating with degraded access (e.g. when SE isn't working that well, or when MS is down). My intent is to merge many/most of the those changes into the release version of FIRE (some changes have already been declined (i.e. flagging through the SE API), so not all of the changes will be integrated).
However, some portions of the various sets of changes still have issues which need to be ironed out prior to releasing those portions, which in some cases is a significant amount of work. In other cases, there are dependencies which need to be resolved first.
I have been intending to release a new version of FIRE in the near future with some of the changes which are in reasonable shape, although that's probably not to include the robustness updates, as those still have issues, and change quite a bit of code, which really needs to be rewritten.
As to the expected near-term update: unfortunately, things keep happening in real life, or SE makes changes elsewhere that break critical things in other scripts, thus taking up time I would have devoted to getting a new version of FIRE out (needs integration and testing). Thus, actually getting the next version out has been delayed.
@Das_Geek np. Having something that works for people is important. I was going to say that I if I had thought the problems would have taken this long to resolve, I would have tried to push out a new version yesterday. However, I really had things that had to happen in RL yesterday, so I wouldn't have been able to get it done. In theory, the problems were expected to be resolved by now. Clearly, they haven't. I'll check around to see if SE status has been updated, so we can get an estimate.
@Das_Geek BTW: Bugging me about updates is fine to do, as long as it's done in a reasonable manner. In fact, as long as it doesn't get to where it's badgering, it's helpful.
@Das_Geek Actually, thanks for reporting this. The specific issue is something that will randomly affect people, depending on when FIRE's cache of the sites data is expired. Given that it's cached for 7 days, it will currently only be affecting 1/7, or so, of people using FIRE. Let me see if there's a reasonable way to resolve this without having to wait for SE to resolve their problems. The data does have information specific to each user, so it's not just something that's a copy-&-paste.
@Makyen Glad to help haha. I had thought about just making an issue in GitHub, but I figured it was more of an anomaly since you had been using the script.
As a side note, what's generally considered the "threshold" of approved PRs before it's kosher to request the blacklister role? I imagine that'd be something I'd request eventually, given that I do use the related commands somewhat frequently.
@Das_Geek There's no specific thresholds defined. In the past, unless the person is actually requesting the role, then it's been done when it's noticed that it's more of a pain to approve the PRs than it would be expected to be to review the watches and blacklists that they would do which are directly applied
Given that it's relatively difficult to review watches and blacklists which are applied directly (they have to be noticed in the transcript, or someone has to go looking for them), that largely means undo issues an improper/erroneous watch or blacklist causes if it's left in for a while. That doesn't mean the person makes no mistakes. We all make mistakes.
So, all-in-all, I don't have a definitive answer for you.
@Makyen Gotcha. I think the only time one of my PRs has been denied is when I watched but a blacklister wanted it blacklisted. Hopefully I am able to continue this pattern.
@Das_Geek just to corroborate what Makyen said, we have decided to not declare a specific threshold also because we don't want to introduce any gamification targets
weirdly some people get over-eager when there's a milestone of some sort
@tripleee Of course. The reason I asked about thresholds was to get an idea of when it would be appropriate to request the role, mainly to avoid the appearance of over-eager behavior like what you mentioned.
@Das_Geek That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer; append -force if you really want to do that.
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Potentially bad keyword in body - Position 0-17: digitalnadeem.com Potentially bad keyword in title - Position 0-17: digitalnadeem.com Potentially bad keyword in username - Position 0-17: digitalnadeem.com
If you're having problems using FIRE due to the current SE API issues, you can execute the following command in your browser's JavaScript console for the chat page, which should restore much of the functionality:
@double-beep Good catch with the .-marketing-link class, btw. Tried looking for a unique something to id it by, but I must have glossed over it somehow
> Url in title, pattern-matching website in body, pattern-matching website in title ---------- Pattern-matching website in body - Position 0-51: http://docs.pickrr.com/#api-Service-Pincode_Service Pattern-matching website in title - Position 0-51: http://docs.pickrr.com/#api-Service-Pincode_Service Url in title - Position 0-22: http://docs.pickrr.com
@EJoshuaS-ReinstateMonica In general, if the question is about a specific topic and the answer is linking to official documentation for that specific topic (i.e. it's not someone coming in and saying "go use mine, it's better"), then disclosure of affiliation has generally been considered to not be required. An example that's used is that it wouldn't be reasonable to make all Microsoft employees or affiliates declare their affiliation every time they link to official Microsoft documentation.
Obviously, there are a number of situations where that doesn't really apply (e.g. spam seeds and their answers), etc.
But, overall, no, I would not consider that answer, or the users other answers, to be spam. (although, I would like to see disclosure on the one that only links to GitHub).
^I copied the above from SOCVR, once I realized the more general question was asked here.
If you're having problems using FIRE due to the current SE API issues, you can execute the following command in your browser's JavaScript console for the chat page, which should restore much of the functionality:
@tripleee Those may be specifically for GitHub Apps, but I'm not sure. You can have a "machine account" in addition to a personal account, but I don't know if it's given the [bot] identifier. An SO question with a bit of info: What is a "bot account" on github?
@tripleee Those may be specifically for GitHub Apps, but I'm not sure. You can have a "machine account" in addition to a personal account, but I don't know if it's given the [bot] identifier. An SO question with a bit of info: What is a "bot account" on github?
