I noticed that, too.

I guess it is a consequence of the fact that the Flags didn't really make any changes to the page. They merely updated the information about the page in a separate place, and used javascript to display it as needed and/or updated the relevant external links.

Unfortunately, along with the template it removed the category en masse from all those pages, and all logs related to that are also gone. I guess it is a good thing they weren't widely used, or this may have caused a big "outrage".

Sounds like Flags wasn't great from the design standpoint if removing it effectively equals loss of data.

It was probably an issue with how the maintenance / cleanup script was deployed. The current design of pages is what is actually problematic. For instance, categories are glued to a page. They can't be changed or renamed without doing that to all pages. That is a serious design flaw.

Another example is the so called notice templates. If the criteria for their inclusion in a page is changed it can't be updated for all of them. The template will still remain in a page until it is removed manually or by a bot. While readers may not notice any difference because they only see the HTML,  the template still generates quite a lot of unnecessary maintenance work for editors.

The bottom line is that maintenance / notice templates are like editors' draft notes that should never be part of live / published work.

As far as I recall, I have not seen any reports of that until you just said this, and we posted notes about the retirement on every community where flags had been used.

If you have examples, please send them in to Special:Contact/bug (if you have not already done so). The sole purpose of the bot was to restore this data before flags was retired.

FWIW: we generally liked that flags was treated like 'metadata' for an article, stored outside of it (thus allowing it to be manipulated separately). However, it just ended up too complex to really be helpful.

Well, you can look at all pages here: http://portability.wikia.com/wiki/Mentoring:Requests/completed.

Most if not all of them had templates added using Flags. My expectation was that it would simply remove the flags, and add the content (template) within them back to the page. 

You'll note that all those pages are still categorized within different "forums" (new request, on hold and completed) because that was the last state of the cache. Or maybe you won't see it if you never visited those pages and the cache is different for you.

> FWIW: we generally liked that flags was treated like 'metadata' for an article, stored outside of it (thus allowing it to be manipulated separately). However, it just ended up too complex to really be helpful.

I still think it is a worthwhile idea to pursue. Maybe using a different implementation or form. Meta-data shouldn't generally be stored within a page. For one thing VisualEditor, and other editors seem to randomly put the category data anywhere in the article which seems to annoy some editors. Removing it entirely from wikitext would eliminate the need to fight pointless things.

See also:

> http://portability.wikia.com/wiki/Category:On_hold_requests

My guess is that a null edit will make all those category memberships disappear. Or they'll eventually disappear on their own.

I would report it, but since this was an experimental feature I'm not sure if it is a bug or simply how it was always expected to work.

The idea behind Flags was a good one. Perhaps it should have used reserved subpages or something like that. It serves as a further lesson that being careful with initial design and not just rapid development plus iteration needs to be considered.

When Flags was retired, any content that was contained within the flags system was supposed to be copied back on to article pages.

The three articles listed in http://portability.wikia.com/wiki/Category:On_hold_requests all have the category in their wikitext, so it won't be going anywhere. Given that flags has now gone, it's a bit hard to say what other pages should or should not have had edits made.

However, the retirement bot definitely ran here: http://portability.wikia.com/wiki/Special:Contributions/Wikia shows the relevant edits on March 9.

Unless I misunderstood something, there is no template (or category) generating that category in the page :

http://portability.wikia.com/wiki/Mentoring:Draconian_Empire_Wikia?oldid=8214

What you see there is simply the left over cache. In fact, if you look at the page itself it doesn't show any category. It will immediately be removed from that category if you null edit the page. I've seen this before so I'm 100% sure it is generated by changing a category without saving the page. The link table and category membership is not updated until a null edit. In my case it was changed by a lua module based on a date without changing any page content. In this case the bot also didn't touch the page and merely removed the api and whatever logs were related to it.

That forum (Mentoring:Requests) depends on the categories to put the pages in their sections. That's why it still "appears" to be correct, once all pages are purged from the cache, link table and category membership, they'll all end up as "open / active" requests.

See also: http://portability.wikia.com/wiki/Category:Closed_requests

The only reason I haven't fixed them yet is just to show you that they do have issues. Although it will be "more painful" to fix once all their cache is cleared.

P.S. I don't think it is really a bug, it is more of a feature to improve performance by disallowing random cache purging.