All The Tropes Wiki Project, Part XX

[GethN7]

After a close read-through, I can't think of anything more at this time.  Such declarations have never stopped us from finding things to add after the fact, but that's no reason not to put it up on the wiki as a proposal right away.

Done: https://allthetropes.org/wiki/Blog:Propo...t_accounts

[robkelk]

I just thought of one more item for the bot policy, but I don't know how to word it yet.

Who's allowed to run a bot on ATT?

The two extremes are that we let anybody run one (including people whose changes are still subject to moderation), or we restrict bots to Bureaucrats only. Do we set the permission point somewhere in between those extremes?

[Dartz]

What about users who are intelligent bots?

Those of us who are not of human born need rights too!

[Bob Schroeck]

<snrk>

To answer seriously, I'd say admin staff and select long-term users with demonstrated records of good edits. However we want to phrase that latter part in the final form, it should set a very high bar -- this should a privilege restricted to only the most trusted users.

[GethN7]

<snrk>

To answer seriously, I'd say admin staff and select long-term users with demonstrated records of good edits.  However we want to phrase that latter part in the final form, it should set a very high bar -- this should a privilege restricted to only the most trusted users.

Concur. The owner of InternetArchiveBot only got their rights because their work has been used elsewhere and they came with impeccable credentials of their intent and responsibility.

Besides, the bot flag allows normal API limits to be exceeded and edit numerous pages in a manner not shown by default on recent changes unless you explicitly decide to show bot edits, so the potential for chaos would require a proven record of trustworthiness.

I'll add rule on that to the post.

[robkelk]

There's a permission level that we currently don't use: Rollbacker. (Anybody that we trust with that much power already has Admin, so it's currently redundant.) Perhaps that would be a good level - if we trust you enough to undo somebody else's contributions, then we trust you enough with a bot.

Thoughts?

[GethN7]

There's a permission level that we currently don't use: Rollbacker. (Anybody that we trust with that much power already has Admin, so it's currently redundant.) Perhaps that would be a good level - if we trust you enough to undo somebody else's contributions, then we trust you enough with a bot.

Thoughts?

That might be good, since it's basically an elevated right between regular user and admin, and those we'd trust to rollback edits (which is what I used to undo the damage from my bot misfiring beyond what it should have) would be a good litmus test for potential bot users.

Again, this should apply to regular contributors at least. the owner of InternetArchiveBot was only able to be approved so quickly because they are an experienced user who has been of immense benefit to the Wikimedia Foundation and came with a ton of credentials proving them trustworthy, so unless they line up a ton of external credentials and a past history of using bot accounts for good purposes elsewhere, then I'd be in favor of making bot rights an earned privilege based on consistent good edits, with those granted rollback rights being prime candidates for bot approval.

[Bob Schroeck]

And it's a right that a bot operator would need in order to handle errors -- and let's face it, no matter how strictly we vet bot operators, an error is going to happen sooner or later. Concur.

[GethN7]

And it's a right that a bot operator would need in order to handle errors -- and let's face it, no matter how strictly we vet bot operators, an error is going to happen sooner or later.  Concur.

Will add to the proposed rule list.

[GethN7]

Okay, something occurred to me, where do we want to keep records of previously authorized bot jobs for transparency purposes?

Here are several ideas:

1. Designated forum thread on the WikiForum provided forum.

2. All The Tropes Project namespace page archive

3. Flow talk page of the Bot rule page where all discussions on approved bot job can be archived.

4. An off-wiki repository (not my recommended solution)

Wherever we keep records of bot job requests, we need to have it in a generally reliable place easily discoverable by users, with no information obfuscated unless required for legal reasons (like using a bot to mass edit pages to remove libelous materials upon proper legal request to remove the offending content)

[robkelk]

Okay, something occurred to me, where do we want to keep records of previously authorized bot jobs for transparency purposes?

You have an extra word in that question.

Let's start with the question you should have asked:

Do we want to keep records of previously authorized bot jobs for transparency purposes?

I'd say "no". We already have Special:RecentChanges - why duplicate it? (Yes, I know we duplicate Special:Categories with Category:Index Index. That's no reason to repeat a mistake.)

[Bob Schroeck]

I don't think that's what Geth's asking, Rob. I think the question is more like, do we want a central place where the purpose and intended changes of each bot run is logged, so we know what was intended and why. Not a record of every individual change.

I think that would be a good idea, especially if the regex (or pseudocode) for each change is included in the log. That way more than one set of eyes can look over what is to be/was done and catch any errors.

[GethN7]

I don't think that's what Geth's asking, Rob.  I think the question is more like, do we want a central place where the purpose and intended changes of each bot run is logged, so we know what was intended and why.  Not a record of every individual change.

I think that would be a good idea, especially if the regex (or pseudocode) for each change is included in the log.  That way more than one set of eyes can look over what is to be/was done and catch any errors.

Exactly. That way we can avoid mass unauthorized changes that result in hassles like my little snafu.

Also, Index Index does not fully replicate Special:Categories.

The former is a list of mainspace-specific categories.

The latter include those relevant to the other namespaces as well.

[robkelk]

In that case, somebody needs to clean up Index Index.

[GethN7]

In that case, somebody needs to clean up Index Index.

It's on the list of things we need to do for sure.

One thing I also want to do is take all the various pages of "unsorted" examples for what could go on new or exist work/trope/creator subpages and trim those down ideally to zero. Not only will we be able to eliminate some redundancy, we can also trim down our list of needed pages, and the more pages of non-cloned content (as some unsorted stuff is clones of stuff on existing subpages), the higher our SEO.

[robkelk]

In that case, somebody needs to clean up Index Index.

It's on the list of things we need to do for sure.

One thing I also want to do is take all the various pages of "unsorted" examples for what could go on new or exist work/trope/creator subpages and trim those down ideally to zero. Not only will we be able to eliminate some redundancy, we can also trim down our list of needed pages, and the more pages of non-cloned content (as some unsorted stuff is clones of stuff on existing subpages), the higher our SEO.

That's something that I've been wanting to do as well, but there are so many images that still need their licenses identified that I haven't had time to do much else. Thanks for being willing to take that part of the workload.

[GethN7]

In that case, somebody needs to clean up Index Index.

It's on the list of things we need to do for sure.

One thing I also want to do is take all the various pages of "unsorted" examples for what could go on new or exist work/trope/creator subpages and trim those down ideally to zero. Not only will we be able to eliminate some redundancy, we can also trim down our list of needed pages, and the more pages of non-cloned content (as some unsorted stuff is clones of stuff on existing subpages), the higher our SEO.

That's something that I've been wanting to do as well, but there are so many images that still need their licenses identified that I haven't had time to do much else. Thanks for being willing to take that part of the workload.

Anytime. 

Back on the bot policy, while I doubt it will ever be needed for the "constantly running" bots, given those will provide services we find indispensable (like InternetArchiveBot), should we include a "staff reserve the right to ask a bot cease for any reason" clause? Again, not sure we need to, but it's the only other possible thing that we might want to include for some unforeseen edge case.

Also, I was thinking, given bot jobs will not be THAT regular, we should have two pages: one listing constantly running bots, the services provided and by whom, and the other for "as needed" jobs with the same information, and started and finished date. While the MW logs will have timestamps, this will serve as a backup to those logs with all the information on the job done and when at our fingertips. I propose they be established in the All The Tropes namespace as main pages in said space, not talk pages, which each job's info separated by section headings. Further, in the event we need to archive any page, we can simply do so for the "as needed" pages, given it's likely to require it at some point in the future.

I further propose the basic layout for a bot job form (for as-needed bot jobs):

Username of bot owner:
Bot name:
Type of job: (formatting fixes, link replacement, and whatever else is included)
Technical information: (spaced between <code></code> to clearly mark it and to illustrate it is technical specific info, like the regular expressions used)
Start Time (does not have to be super exact, but should be accurate enough to match with log timestamps, listing time given for first bot edit made by the MW logs would be fine as well as the real world date)
Finish Time (same as above, just with final bot edit)
Staff who signed off on the bot job: (a bare minimum of a majority of Staff must concur on a bot job before it is given the green light, or, given our current number of staff, no less than two must approve before the job can begin at least)

We could even make a new boilerplate template for this if required.
Comments by bot owner and staff section would be at the bottom: (for discussing the bot job if changes are needed and any post-job notes)

[Bob Schroeck]

Back on the bot policy, while I doubt it will ever be needed for the "constantly running" bots, given those will provide services we find indispensable (like InternetArchiveBot), should we include a "staff reserve the right to ask a bot cease for any reason" clause? Again, not sure we need to, but it's the only other possible thing that we might want to include for some unforeseen edge case.

That seems reasonable. Better to have the option and all.

Also, I was thinking, given bot jobs will not be THAT regular, we should have two pages: one listing constantly running bots, the services provided and by whom, and the other for "as needed" jobs with the same information, and started and finished date. While the MW logs will have timestamps, this will serve as a backup to those logs with all the information on the job done and when at our fingertips. I propose they be established in the All The Tropes namespace as main pages in said space, not talk pages, which each job's info separated by section headings. Further, in the event we need to archive any page, we can simply do so for the "as needed" pages, given it's likely to require it at some point in the future.

Agreed. So just to make sure I have things straight, we're talking about three separate pages now: an "I Want To Run a Bot to Do X" page, a page to document all the existing repeating bots that do maintenance tasks, and a third page to log the actions of one-off bots, correct?

I further propose the basic layout for a bot job form (for as-needed bot jobs): ... We could even make a new boilerplate template for this if required.

Look reasonable. Are we talking a single page for all bot proposals, or a set of subpages under a subject page?

[robkelk]

I'd suggest subpages. That way, we can annually rename the page for one-off bot runs to "One-off bot runs/$YEAR" and start a new "One-off bot runs" every January 1, thus avoiding making the one-off page so large that it's unreadable.

---

Speaking of one-off bot runs... I'd like one done, please, possibly as the first one under the new rules. We've been creating categories "Category:Works by $CREATOR" as the new infobox gets added to literature works pages, but until recently I haven't been adding [[Category:$CREATOR]] to each page (for example, "Category:Works by Juan Rulfo" does not have "Category:Juan Rulfo", but "Category:Works by Robert A. Heinlein" does have "Category:Robert A. Heinlein")... so there's a couple-hundred categories with a consistent naming convention that are each missing an easily-identifiable category that a bot could add.

[GethN7]

Back on the bot policy, while I doubt it will ever be needed for the "constantly running" bots, given those will provide services we find indispensable (like InternetArchiveBot), should we include a "staff reserve the right to ask a bot cease for any reason" clause? Again, not sure we need to, but it's the only other possible thing that we might want to include for some unforeseen edge case.

That seems reasonable.  Better to have the option and all.

Also, I was thinking, given bot jobs will not be THAT regular, we should have two pages: one listing constantly running bots, the services provided and by whom, and the other for "as needed" jobs with the same information, and started and finished date. While the MW logs will have timestamps, this will serve as a backup to those logs with all the information on the job done and when at our fingertips. I propose they be established in the All The Tropes namespace as main pages in said space, not talk pages, which each job's info separated by section headings. Further, in the event we need to archive any page, we can simply do so for the "as needed" pages, given it's likely to require it at some point in the future.

Agreed.  So just to make sure I have things straight, we're talking about three separate pages now:  an "I Want To Run a Bot to Do X" page, a page to document all the existing repeating bots that do maintenance tasks, and a third page to log the actions of one-off bots, correct?

I further propose the basic layout for a bot job form (for as-needed bot jobs): ... We could even make a new boilerplate template for this if required.

Look reasonable.  Are we talking a single page for all bot proposals, or a set of subpages under a subject page?

Concur on the first.

Second is what I was thinking of.

Third, like Rob said, subpages to prevent things from getting too large as to be unreadable would be good.

As for Rob's bot request, I could easily do that with Gethbot once we have all this ironed out.

[robkelk]

Aargh!!!

"Category:Formats" tracks what Real Life calls media.

"Category:Media" tracks what Real Life calls genres.

"Category:Genre" tracks what Real Life calls cross-genre concepts (and we would probably call Genre Tropes if we were creating the category today).

These are key categories, and none of them have the right names!

Who has time to clean up this unholy mess?

And before anybody says it, I don't care if that's what TV Tropes does.

[Bob Schroeck]

This sounds like a job for Gethbot! <grin>

[robkelk]

I see we have those ugly padlocks on protected pages now...

[robkelk]

Got a list of Miraheze wikis here limited to active "fandom" wikis in English, that we can look through to add "The Wiki Rule" examples to works.

EDIT: Good golly, there are some... focused wikis on that list.

[Bob Schroeck]

I see we have those ugly padlocks on protected pages now...

Where?  I don't see them.