As a former software developer, I take great umbrage at the phrase "computer freak" to describe folks who develop software.

In T123866#3291673, @MGChecker wrote:

Yes, but Notifications are private as well.

In T123866#3283219, @MGChecker wrote:

I think notifying watchers instead of creators is much more effective and useful.

In T164178#3245629, @Niharika wrote:

@Stevietheman I can't find a reference for it now, but the pageviews API does do caching on their end so caching on our end might not be as big a speed boost as it looks.

#4 sounds like it could be done in a fairly straightforward manner, using a temporary indexed database table.

@Samwilson I ran 'All' for my own account, and all the entries looked familiar and highly likely to be correct. Thank you for your work!

I might be the person who said it should work like a watchlist (private), and this is indeed to prevent negative responses as discussed above. I'm willing to wait for it being done this way.

On second thought, I guess it would be a little tricky as some entries' number of edits would be tied with others.

I was just taking a look at this again, and wondered why the entries don't have counting numbers (1-100). Is there any particular reason why this can't be there as well? I would think it would communicate that there are 100 total entries and a user can better mentally picture a slice of the list (say, Top 10 or Top 40).

Thanks. The secret stops here. heh

Is this available for user review (beta) anywhere?

OK, so I'll open a ticket wherever these API developers are. Have a link?

So, let's open a ticket and they will set it as low priority. As long as it's documented in the system would be fine with me.

This was discussed above. You had said that the APIs you use to fix a dead link using an archive didn't return the title from the archive page. Would it be prudent to request that they do?

Would it be reasonable to open a request to have a particular API that is used return the page's title?

It can be argued that way, but with "Archived copy" sticking out like a sore thumb, it calls for addressing, and therefore, additional time is spent, when the bot could have in theory inserted this.

Is editors' time manually correcting titles taken into account in the cost-benefit analysis? The idea of a bot creating new work doesn't seem quite right.

Although I'm in no position to mentor, I'd like to help with brainstorming ideas too. I personally like the simplicity of the dashboard on Discogs.com (seen if you have an account).

There are still popular pages listings going empty, with examples Anarchism, Louisville, and Kentucky. When is the bot scheduled to fill these (and presumably others) in?

Please close this ticket as a duplicate of T160721. I had meant to create this as a subtask.

In T156857#3107265, @Niharika wrote:

This ticket was only to build a basic bot from my understanding (3 story points). It's covered way more than that. If there are any other things the older bot did and you don't see them in the current bot, please file new tickets for them. It'll make our job easier. If you don't want to do that, I can file them, just list them here. Thanks.

In T156857#3107624, @kaldari wrote:

New ticket for leaving headers and categories alone when updating the report: T160683.

In T156857#3107444, @kaldari wrote:

Do you have any idea why geography WikiProjects have adopted this practice? In other words, why do folks not want to either define the Louisville group as an actual task force or give it it's own banner? Having it as both simultaneously is confusing and doesn't work well with PageAssessments.

I know there was a push a few years ago to standardize the names of WikiProject banner templates, but apparently this didn't take into account WikiProjects that were piggybacking as task forces. Perhaps there could be another clean-up drive to fix these. Any thoughts on that? This isn't strictly necessary to get Popular Pages bot to work for them, but it's going to be a recurrent problem for any software we build for WikiProjects (which I would like to do more of).

If I have a suggestion for improvement, should I open a separate phab ticket? I would like to see a "Top edited pages" list that shows the top 100 pages from all namespaces together.

Note that I now see the ticket for handling the redirects.

Also, I'm unsure why this is marked as "resolved" as the bot doesn't yet do all the things the previous version did.

Issues I see:

Kudpung, I don't see how comments like yours are constructive, much less advance this along. There are big ideas I'd like to see happen too, but I would not use a strategy like yours. Unless you chill, I have nothing else to say here.

This proposal didn't make the top 10, thus it's not a core Foundation priority, but I think being at #14 makes it appealing for developers to take on. Also, I don't think we should ever assume that something could have been done in a certain time period because many other things have been developed in that time frame, and there's only so many active developers to go around. If one thinks this should be prioritized higher, one should make that case.

I'm thinking this should apply to major editors of a page as well. I regularly run into articles tagged for deletion where the creator is long gone, but editors who touched it quite a bit along the way are still around. The current approach of maybe sometimes the creator being notified (like if Twinkle is used) has led to charges of our delete processes being sneaky. See https://bbs.boingboing.net/t/40-of-wikipedia-is-under-threat-from-deletionists/95250

I was thinking of Muhammad Ali as a good example as well. Thank you for your quick response. I do agree this should be incorporated into results, for sake of fairness in comparative results.

Something related to this just occurred to me. The previous bot was stated to "aggregate the views for all redirects to each page." I assume this meant that views to each page would be counted whether directly viewed or arrived at by a redirect. Is this applicable in any way to what is being worked on right now?

I'll just chime in to say that I'm comfortable with where this part is heading. Thanks everyone.

I haven't looked at this ticket for a week, and it looks like a lot of discussion has flown past me. Anyway, as a former programmer, JSON is simple for me to update, but most Wikipedians aren't programmers.

In T156856#3024025, @Niharika wrote:

Ah, I mistook that to mean that we use the bot to display the Top 10 viewed pages of a wikiproject on the project main page.

I don't see how a different list entry affected another one, but oh well. Thanks.

Note that there's no consensus to deviate from having a "number of pages" field, and I would oppose deviating from that. It would be unfair to the many WikiProjects not represented in this discussion, for starters.

In T156856#3022460, @Niharika wrote:

In T156856#3022280, @Stevietheman wrote:

On this point, I was hoping to be able to produce a second shorter result for a WikiProject I work on, basically a Top 10 list I can show on the project's front page. Things like this add to the project's public showcase.

Feel free to create a ticket and tag it with Community-Tech. We'll look at it in our next sprint meeting and see what we can do. :)

On this point, I was hoping to be able to produce a second shorter result for a WikiProject I work on, basically a Top 10 list I can show on the project's front page. Things like this add to the project's public showcase.

Technically, doing that would simplify things, but I don't believe the issue was computational expense. I think some WikiProjects simply wanted shorter lists. I can't speak for all WikiProjects on this, so I don't know if everyone would agree to a top 1,000 list.

'Number of pages' is the number of top-viewed pages the wikiproject wants ranked. So if they select 1000, they want to see the Top 1,000 viewed pages from their project. (1,000 was the upper limit in the previous incarnation of this tool)

I appreciate the deference to keeping it the way it is, but the on-wiki config works for me, although if anyone jumps up and down and wants a lookalike to the previous GUI, I won't object as the GUI was well-designed. I think a server-side process for handling errors and perhaps messaging someone who made a mistake in the wiki table is perfectly reasonable. I think those tending to request these pages will be editors with reasonable wiki know-how.

The vector skinning image looks pretty good, although I might have expected the stars to be a bit smaller to fit into the lines better. I can't really speak well to the class/ID matters - a bit over my head, although matmarex's point looks accurate. Reuse sounds good, but if you have to contort code for such, maybe it's better to strike out with some new classes/IDs specific for this purpose.

I'm probably stating the obvious that everyone already knows, but this should exclude spider and bot visits. If we compare to the Massviews interface, we would be selecting 'User' for the Agent. We're only concerned with human visits.

Thank you @Sn1per for your excellent work. This design works for me overall. I just have a couple thoughts:

I'd go with B. I don't see any hard reasons for tinkering with the display of log entries in this context.

@mforns Real-time data, isn't a concern as these are monthly-generated pages, except at the point of producing them. It's certainly better for performance that readers are loading flat pages than running the real-time data grab every time. Why push the servers when we don't have to? If people want to do specific queries on visits, they can use Massviews.

@Anomie, I edited my response to you above for (hopefully) clarity.

Now, I guess we have a different discussion with regards to 'Hide my edits' and 'Hide minor edits', the former being a non-problem in my view, as if one has made an edit to a page, they have cleared/visited it, so there's no point in seeing a recent edit behind it. I think. :)

@JEumerus - that sounds right. I just wonder if there ''are'' any bots using undo instead of rollback for directly preceding edits. If not, this two-pronged fix seems like it will be enough to drive a complete solution.

@daniel, If an approved bot does a rollback or an undo of directly preceding edits, I assume it's performing an approved task and the edits reverted (either way) will therefore not be of interest to the watchlister. If this assumption is not true, I would like to read of a scenario that makes me go "hmmm, wait".

OK, I'm trying to understand. At this point, I don't understand why a rollback would be different from an undo of the directly preceding edit(s), for our purposes here.

Pardon my ignorance, but what does 'Blocked' mean?

I wouldn't distinguish any revert from any bot. Whatever a bot reverts should be taken as bot edits to hide. After all, I believe the user that is hiding bot edits is seeking to see the latest non-bot/non-bot-reverted edit that occurred since they last visited the page.

As for improvements, Niharika's ideas look useful to consider, and I also had one from March 15, 2015 that I submitted and didn't get acted upon. It's basically to show changes from month to month for each entry like how Billboard charts do it. Obviously, the first monthly generation wouldn't show these changes.

I also concur with DanielPenfield's comments in the 2016 Community Wishlist Survey proposal.

I think it should stay on WikiProject subpages, generated monthly as it is now (I think that's what survey voters expected to keep, not have this product changed into something else, noting that changes in the program that generated it probably don't matter to the casual reader). A key to this report's value is its production _for_ WikiProjects. And I want to be able to point people to a page in projects I work for, not a separate tool page.

In the 2016 Community Wishlist Survey, a proposal for fixing this wound up at #47 (tied for #45) out of 265 proposals.

See my sandbox, where I have a template call to "citation needed" followed by one to cn, a shortcut. They both render the same in HTML. The background processing may be different, of course, but what the reader sees and the browser receives is no different in any possible way.

I wonder, though, if bypassing stub template redirects is seen as more important than bypassing template redirects in general. Is using the correct stub template seen as especially critical?

The feature isn't being retained as such, though. It's being highly restricted. One has to jump through technical hoops to use it, and therefore, it's totally the decision of the AWB user when they use it. This really isn't different from deciding to do the same thing manually. And as always, the specific editor is responsible for their edits.

I can confirm this issue with respect to an IP user I am watching. I can't get rid of the block log entry in my watchlist, and I don't want to use the "nuclear option" unless all of my watchlist reviews are completed.

The wishlist proposal related to this issue is listed at #9 out of 265 proposals (technically, tied at #8).

The wishlist proposal related to this enhancement requested is listed at #40 out of 265 proposals (technically, tied at #39). There is clearly at least moderate interest in this.

So, on point, should I (or someone) create a blocking task?

Oh, then it was new to me then. :) I don't think I've used it until just yesterday.

Perhaps. The user UI includes transclusions by default, I think. One can decide to hide them.

I haven't worked with the API, but there is a special page for it here. Perhaps it's a new one.

Note that "What transcludes page (all NS)" works. But my point was that a WLH on AWB doesn't work the same as WLH on the wiki (as accessed from a browser).

Yes. Transcluded userboxes.

Note that this is appearing as a proposal in the 2016 Community Wishlist Survey here.

If this indeed fixes intitle searches too per Wikipedia:AutoWikiBrowser/History, that's great, as I was going to open a ticket for that.

I have created a proposal to implement this in watchlists and RC pages at the 2016 Community Wishlist Survey. Voting started today.

With javascript enabled, as long as there is an immediate way to undo, there shouldn't be a confirmation. We don't have to confirm when we watch/unwatch a page on its page, so it shouldn't behave differently in the watchlist itself.

As of April 2016, the diff popup features "send thanks" as an action. I'd prefer to have this on each line of RC per my request, but at least this gadget update is useful.

Which version of AWB are you using? It has gone through changes since April that may affect this issue. If you aren't using the current version, you will have to manually download and install it, as Sourceforge made changes that rendered previous versions' updater unusable.

T55525 seems like a similar idea.

The link classifier script has helped me out a great deal with identifying redirects on the "Edit watchlist" page. I assume red links are already red without using this script.

Something has fixed this issue in the meantime. A particular page where I had this problem isn't demonstrating the sluggishness I saw before.

In T133326#2586956, @kaldari wrote:

@Stevietheman: The bug already exists: T141154.

I thought this was the bug. Also, what would my bug state and where would it go?

It has been over 4 months since the most recent popular pages updates, and the pages in projects in which I'm a member are getting stale. Is anything being done to resolve this?

In T143182#2561436, @ori wrote:

I can demonstrate this. Try typing into the textarea of each of the pages below in one of the affected browsers (Firefox, Chrome 51, etc.):

This problem happens to me with Chrome 52 or Firefox 48 on Windows 10. I tried the following but none of them helped the problem:

As a workaround, I've written F&R entries to revert placement of the underlinked tag.