You are here: Foswiki>Aotearoa Web>FeaturePol (09 Dec 2005, SmusH)Edit Attach
We do not use this policy anymore because we changed software ages ago (we are using Dada now). -- SmusH - 09 Dec 2005

there is an HTML version of revision 1.3 in our colours here: Aotearoa.FeaturePol.htm the index doesn't work (this was produced by fiddling with the 'printable' version)

AOTEAROA IMC FEATURES POLICY (DRAFT)

What's this 'features' all about then?

What is a Feature?

here are our features

Because IMC's allow open publishing of newswire images, video, audio and text (collectively called 'posts') there is often a lot to go through - we like to highlight the most interesting posts via the centre column of the main page.

A feature is not an extensive piece of text - typically between 100 - 200 words. It is ideally an extensive piece of on-line research which directs people to further information. Here are some good examples: I Global I Melbourne I UK I San Diego

Okay the features are:

  • short and avoid opinion
  • more a resource than an article
  • approved by the features email list
  • and when they fall off the page they go into the older features archive

In Aotearoa IMC, we have an open (join here) and publically archived email list for discussing features so anyone keen can join in - you don't have to read this whole page first!

Purpose of the Features E-mail List:

People on the list can:

  • suggest feature topics
  • draft and revise features
  • approve features for upload to the site (the upload page requires an administrator password - view a password holders list here: PasswordHolders )
  • they are subject to the features list usage protocol

I join I read archive I

How to join the Features List

Because of the large number of nasty things crawling around the internet you may not get onto the features list by simply subscribing to it. The best thing to do is to join the general list and ask them there for clearance. We have no reason to stop you joining the list - we just need to know that you're a person and not a spam machine.

How do we make it all run smoothly?

Feature List Usage Protocol

initial draft by RovinNZ , added to by ClarE

Guidelines

To see an example of how these guidlines work in practice look at this page of our archive.

Writters follow four main steps before a feature reaches the site:-

  • 1.) Emailing a draft of a proposed feature
  • 2.) Emailing to second a proposed feature
  • 3.) Emailing to approve a feature
  • 4.) Emailing to notify the feature has been uploaded

It's important that these steps can be easily followed and are not buried deep into an email like "...and yeah, I like that feature too. When's it going up?" So we try to use the Subject of our emails to show what we are doing:

  • Subject: DRAFT "name of feature"
  • Subject: I SECOND "name of feature"
  • Subject: APPROVED "name of feature"
  • Subject: UPLOADED "name of feature"

This makes things easy to follow - you can see how long the discussion is taking - and you can have several features being worked on at once.

One more thing - if you think you can improve what someone has written - always try to submit a suggested new draft. Drafts two, three, four etc can be submitted by different authors.

How to Write a Feature

Mainly - START EARLY. Approval takes time. Otherwise however you like - the important thing is that it is a useful and informative resource for readers.

If you can, submit the feature in HTML, this saves time for the people doing the uploading. But if you don't know HTML yet, don't worry! It's a computer language and they're confusing. We know - we'll help you! Starting with our HTML for Indy tutorial page. Here are some examples of plain text (no HTML) features: Bypass Feature I GE Feature. Someone then went through those features adding in the HTML code. Here is a draft with both versions available: War on Iraq

Features can be written by email, but we actually have a special site where you can propose and write features together with others and watch them evolve.

How to Upload a Feature

To actually upload a feature article to the A-IMC webpage centre column, you must have an administrator password, which is currently limited to a handful of people who are known A-IMCers. This is for obvious security reasons, such as preventing an unknown person being able to hack our features to bits! The page we use for upload and updates is this one.

Once a feature has been approved on the A-IMC Features list, a feature administrator will make the upload and e-mail the A-IMC Features List to let them know this has been done. Similarly, if dissent has been registered about update already made, a feature administrator will hide the update concerned and e-mail the Features List.

If we need to think again about how we give out administrator passwords - it will be subject to our ProcessDoc - a list of password holders is here: PasswordHolders

When Existing Features Need Updates

Updates are there to allow a feature to be kept `up to the minute' with latest developments.This is both clearer and faster than writing a completely new feature.

A typical update to a feature by adding regional reports would look something like this:

Reports from actions: [ Region one Reports (1 2 3) | Region two Reports (1 2 )]

Whenever a feature is updated the A-IMC Features List must be notified.

Updates made still require a features administrator to actually upload them, so the speed of updates will depend upon having an administrator ready to upload the update.

Updates as separate features/breaking news features

Sometimes we need to make Updates an entire new feature. This is useful when you know an event is going to have a whole lot of fast breaking news I.E May Day Carnival feature which was added to hourly when new reports came in.

To get permission for a breaking News feature, you need to email the features list, stating why and when you need it. The proposal needs to be seconded and thirded before you can do it, and there must be no dissent

Dissent on an Update

Dissent may include dissent on any aspect of the feature update, including dissent on a link in the update.

If someone is unhappy/dissents with an update that is made to a feature, theyshould e-mail the A-IMC Features List clearly outlining their reasons for dissent.

The dissented update must then be removed from the feature (by a features administrator), until the dissent is worked out.

What are AIM's rules concerning features?

The AIM Features Policy:

We have tried to keep the rules minimal. In the context of indymedia rules should only be used to ensure everyone is heard and has a chance to participate.

All features are subject to the following three rules:

  • 1.) Features must be submitted to the features list before being uploaded
  • 2.) Features cannot be approved until a list of the proposed links have been available to the list
  • 3.) Features must wait for two additional people to approve the text, or to be seconded by by one other and no suggestion/ comments/ alterations made regarding feature within 24 hours from being seconded. The 24 hour period renews each time a DRAFT is seconded.[ MrSterile 11 Jul 2003 ]

Why these rules?

Rule one - it's important that people see features before they're uploaded - otherwise we're not working together - we're just columnists.

Rule two - we need to see an HTML version so we know that the (hyper)links are working and are linking to suitable places - often other people can provide even better links to things they're interested in. Better links can be added, but we won't start with bad ones.

Rule three - may change over time as the features list gets bigger - when we need to re-write these documents they are subject to our ProcessDoc


Notes: (not part of the document)

[ Clare ]

--I have completely taken out the fast update/slow update stuff - its too complicated and slow.

--Most of this document is about 'how to make features',only some of it actual rules. which i think this is fine!

[ Duncan ]

--I have used two terms consistently. 'FEATURE' always means a feature and never includes the word '- article' this is to avoid people associating features with other types of writting - I've never anywhere seen what IMC calls FEATURES - they are a breakthrough in online writting!

--I've also stopped refering to 'email loops' and refer now to 'email lists'.

--I never use 'article' to mean POSTS to the newswire - the newswire includes pics etc...

--I only use the abreviation A-IMC not AIM. We need to find a more suitable short name. And use our proposed Maori name more: Te Komako Motuhake. TeKomakoMotuhake

--I only use POSTED to refer to POSTS - other things are UPLOADED

New notes -- RovinNZ - 11 Oct 2002

I think we should find a way to distinguish between adding new links to a feature and changing the text. I suggest we therefor give specific meaning to 'update' and 'change' - UPDATE means the addition of a newly relevant link, CHANGE means changing the text or a link in the text. As such i think something like the 'fast update' thing (which is too complicated to be effective) should apply post addition to UPDATES. while the normal process should apply to CHANGES. Thoughts people? -- RovinNZ - 11 Oct 2002

ClarE - 08 April 2003
Topic revision: r22 - 09 Dec 2005, SmusH
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback