Hi, Jan,
TJ comments inline.

On 11/25/2012 06:50, jan iversen wrote:
I am starting this thread so we have a place, to keep our decisions. I will
also a bit later make a new wiki page, "wiki planned maintenance" where I
(and hopefully also the other administrators) will keep track of the work
done, as well as the work ahead of us.

For now, the sql scripts to:
a) remove accounts older than a year WITHOUT any contributions
b) remove all accounts from the time of the spam period
are being prepared, and will be executed when I get a little opie challenge
solved.

I would like to seek lazy consensus on the following items:

a) In order to keep track of all php/apache/mysql changes to wiki, I will
make a directory "wiki-maintenance" in SVN on level with "trunk". Currently
we do not really know what has been changed, and with the upgrade we have a
nice opportunity of documenting all changes, so it is easier for future
administrators. I know there is a very good page in Wiki (wiki maintenance)
but I would like to have the original files, with all changes in SVN.

+1. We might ask the forum people how they do it (it's a parallel problem to the wiki); they may want to do the same as you are suggesting.


b) open for "create page" again, now that all spam users have been blocked.
Create user will have to wait at least a week and if we do not get flooded
with request, I would keep "invite only" for a longer period.

I believe the spammers still have a backlog of unused (hence, unblocked) accounts, but your script to remove all "spam period" accounts should get rid of those. After that runs, yes, please re-enable "create page".

The problem with both "invite only" and "write delay" is with a valuable class of new users. Ignoring the large number of new accounts that are never used, the "fixers" are the most common new users (one per month or less): they create an account, and immediately fix something, or ask a good question on the Talk page. I would like to cater to them, by making life easy.

c) When reactivation "create user" add a cooling period, like page
http://wiki.openoffice.org/wiki/Documentation/Dashboard/Wiki_Editing_Policysays
we already have.

d) Clean database, for "deleted" pages, unused files.

e) repair "broken redirect", "double redirect", "non categorized pages".
Remark no information will be deleted/changed.

Broken and double redirects are normally handled by sysops, from inside the wiki. At the moment, there are no double redirects (I just fixed two). The broken redirects seem to be related to recent work in the Spanish ("ES") pages; I left RGB (sysop, Spanish speaker) a note to take a look.

"non categorized pages" is a much bigger question. It doesn't take a sysop to add a [[Category:whatever]] line to a page, but what line should be added? Currently there are a couple of hundred such pages. Anybody can do the research (how are the pages that link to it categorized? Or, what top-level category is its home; is there a lower-level category that fits?) and is welcome to help fix these. It's a one-at-a-time job, mostly.


f) Convert all pages to UTF8 (mysql), most pages are defined as latin1, but
some have UTF8 content, this will not work after an update.

g) Make a test.wiki.openoffice.org. This can be done with a simple alias in
apache conf, but should be done with a JIRA ticket.

Of course, before any changes to the production mysql a backup will be made.

Jan

Many thanks for your work.

/tj/


Reply via email to