TWiki.org Website Facilitator Task Team

SvenDowideit proposes an initial TWikiOrgWebsiteFacilitatorTaskTeam, which could start by creating a couple of news webs - such as Governance and Archives, define a policy for use of the topics on twiki.org (as we currently have no policy about giving others copies, slowing Rafael down), and to work on Wiki Gnoming.

As this group grows, we can specialize to separate Webs.

Goals

To keep TWiki.org and develop.twiki.org running smoothly by working on the day to day maintainance tasks, and working to implement the plans of the UserExperienceTaskTeam.

Simplifying the usage modes of twiki.org and automating and building tools to make it possible for more than one person to work on these tasks without running over each other is vital.

Ensure provision of the following services to the TWiki community via develop.twiki.org:

• Subversion repository for the TWiki open-source code and development infrastructure
• Bugs web (including managing lifecycle automation and content)

We aim to provide maximum up-time of this platform subject to the fact that it is a hosted system, and we are not available 24x7.

Ensure provision of the following services to the TWiki community via twiki.org:

• Up-to-date plugins web, reflecting the subversion trunk and latest non-svn uploads
• Correct and reliable functioning of phone-home features, as required by end-user configure

Ensure usual sysadmin expectations are met on both platforms:

• Backups
• Security (including management of bogus registrations and spam)
• Adequate disaster recovery plans and resources
• Documentation and automation of configuration and processes

For the avoidance of doubt, specific exclusions:

• Maintenance of TWiki documentation hosted on TWiki.org
• Structure of the twiki.org site (webs etc) except where it impinges on the service webs (Main, TWiki, Plugins)
• Look and feel of the site(s)

Required Powers

• TWikiCommunityGroup membership
• at least one TWikiAdminGroup member
• and at least one member with a login (root access) to each server. (develop.twiki.org, www.twiki.org, niagra.twiki.org)
  • I'm going to ask for ssh keys, so we can avoid the password thing altogether..
• Membership of a to be created Mailing list twiki-gnomes or similar, which will be the email address that twiki.org, develop.twiki.org and registration etc emails will be directed so that work can be distributed.
• twiki-gnomes will need to be the %WEBMASTEREMAIL% for all TWiki OSS project services - twiki.org, develop.twiki.org trac.twiki.org and svn.twiki.org

ie - everything except the kyptonite.

Tasks

see TWikiOrgWebsiteFacilitatorRole for the begining

• we need to break these into manageable subset tasks, and can create a task management framework as we learn more.
• Remove bogus registrations like "BillClinton", "FooBar" needs a strategy, Policy and focus.
  • Peter continues to maintain the Main web
  • Peter, this is simply untrue. I have, as have others done what we can in the Main web. You are not the sole saviour.
• Develop automation and TWikiApps? to make these manageable and shareable.
  • Sven will start by looking at scripting the monthly tasks.
• Define topic and data distribution policy.
• Update plugins on twiki.org with latest releases to benefit from bug fixes and added features
• watch the twiki-gnome mailing list for bogus registrations, requests for help, login issues etc

Partner Teams

• The UserExperienceTaskTeam !!
• The SystemAdministratorsTaskTeam? - ok, this might actually just be us - TWikiOrgWebsiteFacilitatorTaskTeam

Participants

(d) indicates The following people are currently fully empowered admins on develop.twiki.org. (t) indicates current admins on twiki.org:

• SvenDowideit (d) (t) Proposer and Team lead
• RafaelAlvarez
• CarloSchulz
• ArthurClemens (d)
• CrawfordCurrie (d)
• KennethLavrsen (d) (t)
• PeterThoeny (d) (t)

Lifecycle

Subject to rubber-stamping by the governance team, this team is chartered until April 1st 2009, at which point it will be reviewed.

Contributors: SvenDowideit CarloSchulz RafaelAlvarez CrawfordCurrie

InterimGovernanceTeam contact

LynnwoodBrown will help this team craft their charter to prepare for rubber-stamping by the InterimGovernanceTeam (or the association, if it is formed in time)

Discussion

To make Codev useful again, we need to improve searching, improve Googleability, and reduce its volume to the currently active topic set.

Registration and Topic creation policy for Main web

Peter has spent 10 years keeping Main web clean, removing bogus users, removing unwanted topics etc.

We need to pick up the slack here, and to have a well defined simple followable policy. I suggest:

1. work out a set of preventative measures - for eg, why leave the Main editable by everyone? wouldn't the TWikiCommunityGroup be a better fit?
   • To send the proper message it is better not to lock down the wiki unless absolutely necessary - we are not Sharepoint or Plone. -- PeterThoeny - 11 Oct 2008
   • this is well documented to be a minority position, and one this Team will not be continuing. - SD
2. we continue the requirement that real names are used
3. we move all non-user topic / leftbar topic from the main web to sandbox - no exceptions
   • Task continues to be performed by Peter. -- PeterThoeny - 11 Oct 2008
   • Um, Peter, I have been doing this task as much as I can. It is insulting for you to claim that no-one else is doing it, and it is un-helpful for you to claim it is an un-shareable task. - 11 Oct 2008
   • I have seen several different people keep topics in the Main web cleaned up, especially during the month of September. -- DavidWolfe - 12 Oct 2008
   • It's wonderful that Sven and others help out in the Main web. What I was trying to convey is that it would be more helpful if people help out in the other webs that need TLC. -- PeterThoeny - 12 Oct 2008
   • This task, as with all other Team tasks will not be distributed in this fashion, as its prevents colaboration, and prevents process improvements. - SD
4. we Dissallow Group definitions.
   • Better leave it open for experimentation. Cleanup task continues to be performed by Peter. -- PeterThoeny - 11 Oct 2008
   • this is a well documented minority position - this team will be reducing the need for manual cleanups by improving usage policies and using the power of TWiki to create a sustainable and scalable system - SD
5. add plugin support to keep the TWikiCommunityGroup up to date.

To support this policy (or any other as discussion obviously should occur), we should write a TWikiDotOrg Plugin that simplifies task1 and task2 - through a checklist style interface that lets other Team members know what topics have as yet not been verified, and to automatically move topics, and to email user's who's accounts are considered iffy.

Adding to this plugin something that makes it harder for users to create non-user topics, or possibly, to lock down the Main web so that the users only have write permissions to their own topic (unless they are in the TWikiCommunityGroup?) - with some way for users to comment.

This idea would require determining where things like TWikiInstallation should go instead.

Clearly we need a co-ordination system - for example, I have contacted NuclearTuxedo? , but we need a way to ensure that team participants don't have mixups.

• For regrouping content see WebPageAudienceSiteStructure for a proposal. The success stories would be moved to About TWiki / What is TWiki? / Our Users / User Success Stories -- ArthurClemens - 10 Sep 2008

• As I stated in TWikiGovernanceConsolidated on 07 Sep 2008, I will reduce my twiki.org time to allow other community members to step in, and that I will continue to maintain the Main web with TLC. Please focus on the TWiki web, Plugins web, Support web and Sandbox web, all of which have been neglected since September. See my notes in TWikiGovernanceConsolidated. -- PeterThoeny - 11 Oct 2008

Codev Taxonomy & Folksonomy

While doing TWikiJanitor work, I found out that the some CategoryCategory are redundant with tags (obvious case: stale_content and CategoryStale). I would like to convert all the CategoryCategory topics into tags.

Also I think that this TaskTeam should have the ability to maintain the tag base (ie, remove unused/unappropiated tags).

As for the TopicClassification in Codev, I propose:

• We should revisit the TopicClassification used in the BasicForm, as there are some that may be redundant or not needed.
• Admin topics should have a form on their own, so we can mark gateways, topic templates and forms. It is not safe so assume that all topic template names finish with Template or that form topic names finish with Form. AdminTopic should contain the list of these admin topics.

Regarding Folksonomy, I think that we (the TaskTeam) should define some "canonical" tags so we can all use them the same way, much like I listed the meaning (for me) of some tags in CleaningUpCodevRevisited. This should increase the signal-to-noise ration in those selected tags, or at least give us a common language to describe topics.

-- RafaelAlvarez - 11 Sep 2008

Definition topics

I'd like to remove the 'definition' topics from the Codev web (perhaps move them to a GlossaryWeb), or even replace them with links to Wikipedia etc using a FindElsewhere? like mechanism - T.O doesn't really need to duplicate the internet.

• This is so true, it almost hurts. Creating a container (eg. a web) for those definition topics makes sense as some of them may contain TWiki specific comments that are of some value. -- CarloSchulz - 09 Sep 2008
• If we move all the DefinitionTerms? into a separate web either we would need to move them from time to time (as they will be created in Codev) or modify the topic creator page to create "Definition Terms" in the proper web. -- RafaelAlvarez - 09 Sep 2008
• I agree that it does not make sense to duplicate Wikipedia, it is better to point to details on Wikipedia article. However I disagree to remove term topics from the Codev web. The Codev web is here for community members to learn and to stay ahead of technology. It is good to have some discussion going on on definition topics (such as JSON, Folksonomy, OpenID, SynchroEdit, WebDAV), to have pointers to related Codev topics (such as in AJAX, CSS, CPAN, REST), to point to TWiki or wiki related content (such as TML, WikiCreole), or to alert developers of important new technology relevant to TWiki (such as MicroFormat, YQL). -- PeterThoeny - 11 Oct 2008

Tools

We also need to start putting in place the tools and systems to improve the refactoring of topics - and work on rewriting our Documentation to focus on simplicity.

Included in this is to use more plugins - we use develop.twiki.org to represent future releases (its locked down to using the default set for validation purposes), TWiki.org should show off the best we have to offer.

• This is perhaps where TWikiOrgWebsiteFacilitatorTaskTeam acts on the recommendations of UserExperienceTaskTeam

Define a topic distribution policy

To date, Peter and I are the only (known) backups of twiki.org's data, and because the community has not defined a policy on giving out copies of the data, I have not passed a tgz on to people when they've asked. As an example, Rafael asked so that he could analyse and accellerate his Codev cleanup work.

My preference would be to have a regular set of tgz's that anyone (or perhaps any registered) user can download and use. If its owned by TWikiContributors, why would they not want to allow TWikiContributors to use and learn (and teach) from that data.

Increase topic refactoring

1. We need to get away from the many year old trend of using comment plugin, and then never refactoring the topic. I'm going to start right here on this topic, by moving things around on a regular basis.
2. I'd like to also consider the use of a blockquote tag with styling for comment plugin - and perhaps to change how it works from being 'add stuff to the end' to 'annotate any location in the text'.
3. Also, what if we stop adding 'sig's quite so much, and generate a topic editors list from the rev history.
4. TaskTeams could do with a lightweight TaskTracking? system

Make a public TaskTeam Mailing list, and change the talk admin email to that

This will reduce the workload for Peter (or any one person) and make it more clear to everyone some of the workloads.

TWikiJanitor

We may be able to su-login to be TWikiJanitor? - though right now it would not work like sudo - everyone would need to know the extra password.

---

• CleaningCodev
• WebPageAudienceSiteStructure

With so much focus on automation isn't there a risk to lose the human touch? As I mentioned on 07 Sep 2008 in TWikiGovernanceConsolidated, "I will continue the user account maintenance, but would appreciate help in the Plugins web, Support web, Codev web, and especially in the TWiki web." So for now it would be more beneficial to focus on those webs. -- PeterThoeny - 10 Sep 2008

• Simply put, nope. Automation means we free up more time for the personal touch. -- SvenDowideit - 10 Sep 2008
• If I read correctly, you're not proposing automating the tasks themselves. You're proposing automating a system of notification about what topics might need attention. If so, there should be no worry about losing personal touch. It would still be humans doing the work. The automation simply speeds it up by pointing out the work that needs to be done. -- DavidWolfe - 10 Sep 2008
• I am proposing automating everything we can, including any tasks or sub tasks that are possible. The other thing we're proposing is to create systems that have fewer failure points that require cleaning up. -- SvenDowideit - 11 Sep 2008

For those who want to perform some TWikiJanitor? work on their own, I recommend putting %BLACKLISTPLUGIN{ action="user_score" }% on your personal WebLeftBar, and watch your activity so you won't get banned (this is specially useful to those with dynamic IP which cannot be whitelisted).

Sven, do you want me to change and email the password of TWikiJanitor? to you?

• na not yet - I'm just listing as many 'things' as i can think of -- SD

-- RafaelAlvarez - 11 Sep 2008

At Sven's request I merged DevelopTWikiOrgAdminTaskTeam with this task team. Sven, I think before this can be rubber-stamped there has to be at least agreement-in-principle with TWIKI.NET, who hold the physical keys to the t.o server, and I haven't seen any input from them yet.

-- CrawfordCurrie - 08 Oct 2008

I'll be refactoring out the discussion in the next week

While I was expecting Peter to help out by improving the details of what he used to do (TWikiOrgWebsiteFacilitatorRole is a bit to vague) I'll be refactoring it's content into this topic too.

Crawford - as Peter's commented in topic, we can presume agreement-in-principle. What I'm looking for is assistance in drafting the charter, and then the rubbers.

-- SvenDowideit - 14 Oct 2008

add a 'don't' allow users to create / move / modify topics function to the TWikiDotOrgTeamPlugin? - such as the TWiki.NotExistingYet topic, which is used in documentation to show a non-existant topic.

-- SvenDowideit - 14 Oct 2008

I think that, extending the previous idea, perhaps some topics should be locked to be modified only by the TWikiDotOrgTeam? . Main comes to mind...

-- RafaelAlvarez - 14 Oct 2008

yup - see higher up - we'll lock it to the TWikiCommunityGroup.

-- SvenDowideit - 14 Oct 2008

install SubscribePlugin? and make tmpl changes for UseTWikiDotOrgPageSubscriptionsToRetainCommunity

-- SvenDowideit - 20 Oct 2008

Regarding my request for feedback from TWiki.net - I see that Peter is involved in the discussion of the detail of what the team is doing, so i guess twiki.net is therefore fully engaged. From my perspective, I think the charter given at the top of this topic is sufficient for the team to be rubber-stamped by the InterimGovernanceTeam, subject only to a lifetime. I suggest that the team should be chartered for 6 months initially (until 1st April 2009). I did some tweaking on the charter above.

-- CrawfordCurrie - 21 Oct 2008

This is looking good. Should maintenance of the various email lists fall under this Task Team also? Also, shall me copy over the basic list of tasks from TWikiOrgWebsiteFacilitatorRole and organize them here?

-- LynnwoodBrown - 23 Oct 2008