TWiki.org Website Facilitator Role

Tasks

Daily activities:

• Main web:
  • Remove bogus registrations like "BillClinton", "FooBar"
  • Assist login problems (fix e-mail addresses etc.)
  • Remove non-user topics, or move to Sandbox web
  • Sync e-mail address to .htpasswd if user with old homepage format changes e-mail address

• TWiki web:
  • Fix doc contributions
  • Put into right bucket (DistributionDocument, SupplementalDocument, etc.)
  • Add proper header and footer to new topics
  • Sync content of DistributionDocuments to SVN
  • Fix WYSIWYG edit issues

• Codev web:
  • Categorize new content
  • Tag new content if it needs visibility

• Plugins web:
  • Monitor new extensions:
    • Add/fix PackageForm on extension topic if needed
    • Add -Dev and -Appraisal topic based on template (parent of -Dev topic is extension topic; parent of -Appraisal topic is -Dev topic)
    • Add encouraging / thank you note to -Dev topic
  • In -Dev topics, add constructive feedback on extension
  • Tag extension topics

• Sandbox web:
  • Fix Sandbox.WebHome topic:
    • Remove attachments
    • Remove extra content
    • Move old Sandbox links to archive
    • Fix WYSIWYG edit issues
  • Monitor all sample apps:
    • Remove unwanted changes
    • Fix WYSIWYG edit issues
  • Remove old topics in Sandbox web

• Support web:
  • Help answer support questions
  • Fix incorrect status in support questions

• Other daily activities:
  • Proactively monitor topic changes in all webs:
    • Remove offensive content
    • Roll back topic revision if hit by new spam (not listed by shared spam list)
    • Add new spam signatures to "Local SPAMLIST" of BlackListPlugin
  • Tagging:
    • Remove bogus tagging activity
    • Remove extra tags (similar tags of existing ones) and send explanatory note to person
  • Monitor TWiki logs:
    • Add bad spiders to deny list
    • Bump greedy IP addresses to ban list

Monthly activities:

• 1st of month: Run statistics as documented in TWikiOrgStatistics; update /index.html
• Clean up stale registrations in data/RegistrationApprovals
• Support web: Close unanswered support topics older than 30 days. Review each question to decide if this is a ClosedUnanswered or a AnsweredQuestions.

-- PeterThoeny - 14 May 2007

Feedback and Comments

I updated above list with the activities I do on twiki.org in my WikiChampion role.

Loving care takes dedication and time; I work a few hours a day on twiki.org. I currently have a 14 day backlog on the Main web and Plugins web. I am wondering if I could get some hand.

-- PeterThoeny - 14 May 2007

Perhaps if you indicated what proportion of time each activity takes, people would be able to focus their help.

Just a suggestion, but maybe if you invested a bit of time on automation, you could free up time for more value added activities, and avoid getting caught in this sort of backlog situation. I marked in red some activities from the above list that I would certainly automate/eliminate in your position. I appreciate that these activities may not represent a large chunk of effort, but IME every little helps. This sort of automation is a big help on d.t.o. (see tools/develop for all the scripts we use there) though again I appreciate that it's a lot easier to automate that site.

• Remove non-user topics, or move to Sandbox web
  • daily cron -- CC
  • I like to be nice to evaluators. Not sure a script can decide what needs to be deleted, what stays, what should be moved to the Sandbox web, and to send a explanatory note to the person. -- PTh
• Sync content of DistributionDocuments to SVN
  • Sync content of DistributionDocuments to SVN - daily cron, make use of the doc synch automation script that is currently rusting. -- CC
  • Yes, with some constraints, as discussed recently in DakarDocumentationModelIsBroken. -- PTh
• Fix WYSIWYG edit issues
  • please report any issues you see, or they will never get fixed -- CC
  • I already reported many bugs, will do more. WYSIWYG needs a more radical fix I think. -- PTh
• Add/fix PackageForm on extension topic if needed
  • don't do it; let the person who needs it, create it. -- CC
  • I disagree, the Plugins web is currently in a bit of a mess. I (or another WikiChampion) need to do it, since a nice taxonomy and findability is not at the radar screen of developers. -- PTh
• Add -Dev and -Appraisal topic based on template (parent of -Dev topic is extension topic; parent of -Appraisal topic is -Dev topic)
  • don't do it; let the person who needs it, create it. -- CC
  • (read my comment above). -- PTh
  • This could be easily automated: A script that look for "Plugin", "!AddOn" or "Contrib" topic, checks if the corresponding -Dev & -Appraisal topic exists and creates them if needed. -- RAF
  • It can also be done in the template topic with the help of TopicCreatePlugin. -- PTh
• Fix Sandbox.WebHome topic: Remove attachments, remove extra content
  • daily cron or lock it -- CC
  • Locking down content sends the wrong message to evaluators. Not sure if it can be done reliably with a cron job. -- PTh
• Remove old topics in Sandbox web
  • monthly cron -- CC
  • Could be done, although it can be chanllenging to configure the cron to leave selected content untouched (and update that list). I think it is easier to do this manually, it takes only a minute per month. -- PTh
• 1st of month: Run statistics as documented in TWikiOrgStatistics; update /index.html
  • monthly cron -- CC
  • Already done with bash commands, only copy & paste is manual. -- PTh
• Clean up stale registrations in data/RegistrationApprovals
  • monthly cron -- CC
  • Yes, can be done. -- PTh
• Support web: Close unanswered support topics older than 30 days
  • monthly cron -- CC
  • No, you need a review to decide if this is a ClosedUnanswered or a AnsweredQuestions. I also sometimes answer & close easy questions. -- PTh
  • A special SEARCH or a script that build the "older than 30 days" list could be made (if you don't have it already) -- RAF
  • Yes, it's AskedAndAssignedQuestions -- PTh

-- CrawfordCurrie - 15 May 2007

Thanks Crawford for the feedback. I moved your questions out of the doc section and added my feedback.

-- PeterThoeny - 15 May 2007

I added some more comments

-- RafaelAlvarez - 15 May 2007

I appreciate all the feedback, but IMHO the discussion is focusing on automation that does not give much gain in productivity based on the circumstances. I am looking for encouraging support or help, but I also realize it is more fun to work on new features.

-- PeterThoeny - 15 May 2007

We're programmers, and programmers are inherently lazy; that's why we look for ways to automate. It's hard to contribute to manual processes that you think can easily be automated :-(. I appreciate that you like to be nice to contributors, and afford them individual treatment; but you have to be prepared to compromise, or drown, I suspect.

Putting automation aside, I'll ask again; what proportion of time do you spend on each of these activities? Knowing that would help people focus their help. At the moment I and few others, spend quite a bit of time on the Support web, but if that's not the activity you need the most help with, then maybe we should focus our help elsewhere?

-- CrawfordCurrie - 16 May 2007

I do not track the time I spend in each web. One proxy is to look at the number of topic saves. Here are the numbers of a recent month: 203 Codev, 168 Main, 133 Plugins, 106 Sandbox, 143 Support, 37 TWiki. The Main web is underrepresented because it does not include removing accounts, removing/moving content to Sandbox web (done on shell level for speed.)

Last night I spent 2+ hours to garden 7 days worth of contributions in the Plugins web (cleared half of backlog). I changed/created 36 topics, of which 11 where new. The new topics could be automated. However, a simple copy & paste takes only seconds; the bulk of the time is spend on encouraging feedback, and on fixing and tagging content. I think spending more cycles on automation does not address my question.

-- PeterThoeny - 16 May 2007

Let's consider these web by web, and see what we can do to help:

• Codev - looking through your recent comments on Codev, it's hard to know what to do there that (active) people are not already doing, as most of your comments are expressing your view of an issue, or documenting something you have thought of / discovered. There is no doubt some of us should spend a bit more time on positive encouragement, though.
• Main - AFAICT there doesn't seem to be much other people can do to help you in Main web; that's an admin function, and you have always kept that to yourself, so it's hard to help there (unless it's with automation, which you don't want). perhaps more activity from TWikiAdmingroup is what you are after there?
• Plugins - there is no doubt that more people can help out in Plugins; the processes and procedures should be pretty clear by now, and there's really no excuse.
• Sandbox - ditto, I guess, though it would help to know your criteria for managing topics in this web.
• Support - there already seems to be a reasonable level of activity here, though of course more is always better, especially when clearing a backlog.
• TWiki - you know my view on this; the sooner it is synched with Subversion and automated, then the sooner your workload will drop here.

re: "fixing and tagging content" - tagging is no doubt a good idea, but fixing? I noticed yesterday that you had edited 5 of my recent contributions to support web, to change the formatting; delete blank lines, escape wikiwords etc. Can you perhaps lower your standards there a bit and allow just the occasional formatting error through? I'm sure it would save you a lot of your time if you didn't attempt to comment unless you had significant value to add. Please don't take this the wrong way, I'm trying to help, but FWIW I think you should be a bit more Olympian in your approach; allow minor formatting errors to pass, so that people say "wow, look, Peter contributed" and rush to read your words, rather than ignoring your edits because they often turn out to be minor.

So, in summary, I think the following actions are needed:

• Peter - spend less time fixing formatting, more on creating high value, Olympian feedback
• TWikiAdminGroup - help out Peter in Main web
• Customer advocates and developers - positive encouragement in Codev
• All - answering Support queries, gardening Sandbox

-- CrawfordCurrie - 17 May 2007

Re-reading this, I realize that the TWiki Facilitator has too much responsability. I think that this Role should be split by web.

-- RafaelAlvarez - 08 Sep 2008

It would be great if people would step up to form maintenance task-teams for the different webs. It sounds like an initial flurry of activity from some determined people would result in a lower load for everybody in the longer term.

-- CrawfordCurrie - 09 Sep 2008

how about we start with TWikiOrgWebsiteFacilitatorTaskTeam, and then form sub groups as we have enough joiners?

-- SvenDowideit - 09 Sep 2008