Content Types And Access Control

Here are the ideas I have so far on how to initially manage content. It can get a lot more sophisticated but this will mostly work with the software and limited involvement we currently have. These are higher level categories - I haven't considered lower level categorisation, lists, tables of contents and naming schemas, but we can use the page associated with this talk page to explore that structuring.

Content should be classifed as official or unofficial. Anything that is topical in comp.lang.c is topical on the wiki, with additions.

The official content should be fully under the control of trusted expert/senior moderators from clc. These moderators should be notified of changes to the content so that they can monitor each other's edits. No one other than the moderators should have the ability to create or edit pages with official content. Official content should be classified as:

1. provable facts (e.g. language syntax, standards-defined issues, language history); should be 100% accurate and reliable at all times
2. easily supportable and representative clc views (e.g. casting should be avoided where possible; gets should not be used - of course the reasons why it is dangerous fall into category (a) but the advice against its use fits this category; the definition of lvalue is broken in C99)
3. less universally representative clc views (e.g. style issues); this content may include various alternatives along with a pro-con analysis
4. opinion pieces by individual or groups of clc contributors (e.g. on a proposed change/addition to the standard); the contributor need not be an official moderator but of course a moderator will have to add the contributor's content to the official part of the site after first vetting it for appropriateness and probably running it past the other moderators too.
5. different ways to solve a problem with a pro-con analysis of each (e.g. overflow checking on integer arithmetic)

Demonstration source code may be contained within any of this content.

The associated talk pages for each official content page should be classified as unofficial content; they should be more accessible to allow people other than the moderators to comment on errors or lacking content and to propose new content or collaboratively edit content. A very visible disclaimer at the top of the talk page should indicate that content is not official or fully under the control of the moderators and may not be accurate or representative of clc. The moderators may at their discretion move content from the talk page into the content page.

In future we might support both individual-controlled and collaboratively edited group areas containing unofficial content.

Technical Issues

• There isn't currently a way to allow a user to edit talk pages whilst at the same time preventing them from creating new pages that only moderators (who will have to be sysops) should be able to create.
• Email notification is quite limited - there is no way to be notified according to broad criteria such as pages that are added to a category or linked to from another page or contained within a certain namespace; this is especially relevant to newly created pages which can currently only be notified for specific predetermined names. Actually, looking at the Enotify features it looks like there should be an option to "Send me an email when a new page is created" but I can't find an option in DefaultSettings.php that enables this (not even in the latest CVS commit for DefaultSettings.php).

I believe that there is a seperate enotify project based on mediawiki. I think they take the mediawiki code and patch it.
--Flash Gordon 21:03, 20 September 2005 (BST)

I thought they'd fully integrated that into mediawiki 1.5, but perhaps not.
--Netocrat 16:50, 21 September 2005 (BST)

Adding/Removing Moderators

To start with, as Flash seemed to agree in email correspondence, this will simply be determined informally by consensus of the current set of moderators, with the current site admin (i.e. Flash) having default status as arbiter in the event of disputes. Again it can become more sophisticated but unless/until conflict emerges, we don't need to deal with that. Let's try the simple approach first and encourage harmony.

--Netocrat 08:55, 8 September 2005 (BST)

Informal concensus is the best approach. If this does not work I would be happier with a more formal approach than me acting as arbiter. My "special powers" come entirely from that fact that I can walk up to the server, log on as root, and do anything to it I want not because I want to take control. Other members of comp.lang.c are better qualified than I to determine the correctness of C code.

--Flash Gordon 21:00, 20 September 2005 (BST)