AFS Admin Todo

From AFSWiki

Purpose

This is a repository for projects that require an admin, but that we haven't had a chance to work on yet. In theory, any admin should be able to perform these tasks, so this is a poor man's work queue for all of us. For standard admin processes, see AFSWiki Administration.

Please list one of the following priorities

Urgent: This could not be completed by one of the admins, but it needs immediate attention. In theory, there should be very few of these, but if you see one, please try to complete it straightaway.

Required: This has been agreed to as something that AFSWiki needs to meet its goals and obligations.

Good Idea: This is something we should do. Please work on these when you find some time. They are a great way to contribute.

Nice to Have: We have lots of good ideas, and you can work on them or not. Some ideas will appeal more than others.

Long Term: An idea for the long-term future, but not in the next few months at least.

Unprioritized: Not clear yet whether this is worth doing, but it's being posted here to avoid forgetting this idea someone (else) once had. Delete if you understand where that person was coming from and know that it's not a good idea.

When you have a new task, please add it here. When you have completed one, leave the idea showing, but move it down the list and show it as strike-through.

To-dos: Urgent, Required, and Good Ideas

1. Move New User Email to HTML (Good Idea)
2. Add a forms extension (Good Idea) so that we can create wiki versions of AFS internal forms and allow wiki users to fill them out and submit them online. Examples where this would be useful:
   1. the request for references when someone wants to become a registered AFS volunteer
3. The database is set up so searches for terms shorter than 4 characters will never work. That means people searching for what "PWP" or "CP" or "stu" means will probably get frustrated. (Good Idea)
4. Automate backups. (Good Idea)
5. Add SSL support for login pages. (Good Idea)
6. Research local httpd.conf changes to support pointing at a test instance (Good Idea)
7. write an ssh sequence to do remote backups, as we don't have cron for our basic account with pair.com (Good Idea)
8. Add MX record for afswiki.org, so that mail not to the www.afswiki.org account doesn't bounce. (Good Idea)
9. Add a patch that allows world-readable pages to be specified through regular expressions so that we don't have to exhaustively enumerate the many, many pages we'll want to whitelist (Good Idea, as long as we're careful with it, e.g., only applying it to an entire namespace so it's clear what is or isn't whitelisted)
10. Add a copyright notice to each page to discourage use without permission by other organizations (Good Idea). There's a standard place for this in the config file. General info about non-profit copyrights.
11. modify the Private:AFSWiki Edit Anonymously Readable Whitelist process so that the whitelist is held in a separate file from the rest of the LocalSettings -- e.g., in a data file instead of the main script. That will reduce the risk that we'll clobber the script during the frequent updates of the whitelist. (Good Idea)

Todos: Nice-to-Have and lower priorities

1. revise contents of Special:Confirmemail to show "next steps" a user can or should take after setting up a new account (Unprioritized)
2. Look into how Powerpoint slides are stored. Can we host those slides in a more wiki-like way, e.g., using something like Lightbox, if we want to offer inline display and review (aka self-guided education, compulsory stuff, review for students, etc.)? Maintaining one central doc is better than maintaining multiple versions. (Nice to Have)
3. (Nice to Have, unless we discuss and it becomes required) Revise configuration so that notification that a watched page has changed won't contain broken links. In the example below, the two links under "Contact the editor" don't work. Until we make this change, we can't use the page-change-notification functionality as a broad-based way of keeping the community updated when articles on a "News" page get updated. Here's the example.
4. Look at harvesting account creation information from logs. Can this be reported on in a better way than by search from the Logs page. (Nice to Have)
5. Automate identification of related articles in partner countries' wikis. An AI professor writes: "I think that there has been work on this under the heading of "cross-linugal information retrieval". I know that there have been workshops on this at SIGIR and at IJCAI. The problem doesn't seem hard actually (assuming you can translate the words [using a service similar to [1]]) because then you just compare the cosine distance between the term vectors representing the various documents. Don't know of a tool/engine that does this, though" (Long, Long Term)
6. Look at .css for all skins and test using afs-logo-preferred.jpg (in home directory) in place of afs-logo.gif (currently in use). (Nice to Have)--> See discussion page regarding bullet point.
   • Select the best skin (or create a new one) and set as the default. Skin options can remain, but need not be supported for user issues.
   • For the default skin, create .css selector to strike-out links not on the whitelist to provide the reader a visual indicator.
7. Look at Mediawiki Category Considerations. It would probably make sense to add extensions for Category intersections and unions (Unprioritized)
8. To help keep the wiki DRY, connect it to an automated tool that detects when two pages contain an identical, long series of words. The tool is just part of this effort; the more tedious part will be actually re-organizing the text to eliminate the redundancy. (Unprioritized)
9. Consider adding a category for pages that are anonymously readable. (Unprioritized)
10. Also for pages that are anonymously readable, add an automated, blatant warning that any (non-anonymous) person who is editing that page will see, so they are a bit more careful about what kinds of comments they add to such pages. (Unprioritized)
11. Move a lot more of the page titles to AFSWiki Anonymously Readable Whitelist so that people don't have to log in to get information that doesn't need read-protection. (Unprioritized)