Talk:Community Updates/Draft

From Openmoko

< Talk:Community Updates(Difference between revisions)
Jump to: navigation, search
(Filling "Edit Summary" field: = fixed typos, better look)
(Date format: +arguments for date formatting)
Line 26: Line 26:
  
 
==Date format==
 
==Date format==
Dates in article body text should all have the same format. Use one standarized date format. Current version of media wiki software is {{CURRENTVERSION}}. When it will be 1.15+ we can use unified date format, which would be represented accordingly to predefined user's preferences, while showing some default format for not registered users. (Is there any chance for upgrading this wiki version?)
+
Dates in article body text should all have the same format. Use one standarized date format. Current version of media wiki software is {{CURRENTVERSION}}. When it will be 1.15+ we can use unified date format, which would be represented accordingly to predefined user's preferences, while showing some default format for not registered users. (Is there any chance for upgrading this wiki version?) Here is nice example of [http://www.mediawiki.org/wiki/Help:Variables#Formatting date formating]
Here is nice example of [http://www.mediawiki.org/wiki/Help:Variables#Formatting date formating]
+
 
 +
You might wonder wich date format to choose? Many will say: 'use "DD, month YYYY" because it is easy to read for human'. But I say it is easy to read only for those humans born in UK or USA. For the rest of world, people's brain has to do additional task of translating english_month's_name into your local_month's_name. Another argument of mine is that there are plenty of countries where official date format is YYYY-MM-DD, MM-DD-YYYY or else. So, how to achieve consensus? Answer is simple: use international [http://en.wikipedia.org/wiki/ISO_8601 ISO_8601] standard. In short it says:
 +
 
 +
''"The signature feature of ISO 8601 date and time representations is the ordering of date and time values from the most to the least significant or, in plain terms, from the largest (the year) to the smallest (the second)."''
 +
 
 +
Thus, as a conclusion, official date format for Community updates should be '''YYYY-MM-DD'''. Additionally this is most natural format for sorting purposes.
  
 
==Filling "Edit Summary" field==
 
==Filling "Edit Summary" field==

Revision as of 12:07, 30 July 2009

Contents

Welcome

This discussion page is intended to help wiki editors standardize Community Updates (following refer as CU). You can take a look here, to have a feel how coming update would look like, if you follow all these standarised wiki guidelines. Everybody is welcome to help. Following are main topics which should be covered.

Guidelines

Conform to Openmoko_Wiki_Editing_Guidelines. These guidelines covers most of uncertain cases an editor might run into while editing wiki pages. It takes half an hour to dig through this, but is worth to do it at least summarily.

Editing

Conform to Help:Editing

Templates

Conform to Templates. Especially when it comes to handy Semantic boxes, like Template:ApplicationBox:

{{ApplicationBox|
Name=[[Gpe-FileManager]]|
Description=A file manager application with MIME types and remote access support from the the GPE Palmtop Environment (GPE) project.|
Screenshot=Gpe-filemanager.png|
Homepage=http://gpe.linuxtogo.org|
TestedOn=Om2008.8|
PackageName=gpe-filemanager
}}

If application/something else has its own wiki page, put its name in double square brackets:

Links

Keep in mind the difference between internal and external links. Try to use them properly, accordingly to their destination

Date format

Dates in article body text should all have the same format. Use one standarized date format. Current version of media wiki software is 1.19.20. When it will be 1.15+ we can use unified date format, which would be represented accordingly to predefined user's preferences, while showing some default format for not registered users. (Is there any chance for upgrading this wiki version?) Here is nice example of date formating

You might wonder wich date format to choose? Many will say: 'use "DD, month YYYY" because it is easy to read for human'. But I say it is easy to read only for those humans born in UK or USA. For the rest of world, people's brain has to do additional task of translating english_month's_name into your local_month's_name. Another argument of mine is that there are plenty of countries where official date format is YYYY-MM-DD, MM-DD-YYYY or else. So, how to achieve consensus? Answer is simple: use international ISO_8601 standard. In short it says:

"The signature feature of ISO 8601 date and time representations is the ordering of date and time values from the most to the least significant or, in plain terms, from the largest (the year) to the smallest (the second)."

Thus, as a conclusion, official date format for Community updates should be YYYY-MM-DD. Additionally this is most natural format for sorting purposes.

Filling "Edit Summary" field

Many wiki editors do not fill in "Edit Summary" filed under "edit" box. This summary becomes very handy when it comes to later version comparision. Always fill in "edit summary" field when editing wiki pages. All you need to type there are 3~4 words of comment, and really makes life easier for wiki administrators.

It's a good idea to set your user preferences (under Editing) to "Prompt me when entering a blank edit summary". If you really want to keep it empty, you can just confirm the message or enter a blank space to avoid the message.

Creating new templates

Using Template:ApplicationBox is great idea! Why not create similar templates for other parts of CU? The disadvantage of this way would be little more code to fill, but all entries in particular part of CU would have similar layout. Following this idea Template:DistributionBox is currently being developed. You can see preview on Community_Update_Draft in Distribution section.

  • Currently there is voting ongoing on community mailing list. Come on in and vote for your favourite template, or leave comment here!

Community Update releasing process

And last but not least...In fact it is pretty important: never copy/paste contents of CU to release the page! Instead always use "move" button on top of wiki page. This "button" is intended for this action and by using it you save all editions and contributions history.

Mailing list interface

Often there is a need to provide link pointing to discussion on a mailing list. Services providing web interface to mailing lists (like nabble.com) were reported many times to break discussion threads in mail clients. Remember, mailing lists were designed to be used with mail clients, not with web forums. If you need to provide link to discussion on mailing list for those who are not subscribed, use mailing list archives.

Personal tools

Welcome

This discussion page is intended to help wiki editors standardize Community Updates (following refer as CU). You can take a look here, to have a feel how coming update would look like, if you follow all these standarised wiki guidelines. Everybody is welcome to help. Following are main topics which should be covered.

Guidelines

Conform to Openmoko_Wiki_Editing_Guidelines. These guidelines covers most of uncertain cases an editor might run into while editing wiki pages. It takes half an hour to dig through this, but is worth to do it at least summarily.

Editing

Conform to Help:Editing

Templates

Conform to Templates. Especially when it comes to handy Semantic boxes, like Template:ApplicationBox:

{{ApplicationBox|
Name=[[Gpe-FileManager]]|
Description=A file manager application with MIME types and remote access support from the the GPE Palmtop Environment (GPE) project.|
Screenshot=Gpe-filemanager.png|
Homepage=http://gpe.linuxtogo.org|
TestedOn=Om2008.8|
PackageName=gpe-filemanager
}}

If application/something else has its own wiki page, put its name in double square brackets:

Links

Keep in mind the difference between internal and external links. Try to use them properly, accordingly to their destination

Date format

Dates in article body text should all have the same format. Use one standarized date format. Current version of media wiki software is 1.19.20. When it will be 1.15+ we can use unified date format, which would be represented accordingly to predefined user's preferences, while showing some default format for not registered users. (Is there any chance for upgrading this wiki version?) Here is nice example of date formating

Filling "Edit Summary" field

Many wiki editors do not fill in "Edit Summary" filed under "edit" box. This summary becomes very handy when it comes to later version comparision. Always fill in "edit summary" field when editing wiki pages. All you need to type there are 3~4 words of comment, and really makes life easier for wiki administrators.

It's a good idea to set your user preferences (under Editing) to "Prompt me when entering a blank edit summary". If you really want to keep it empty, you can just confirm the message or enter a blank space to avoid the message.

Creating new templates

Using Template:ApplicationBox is great idea! Why not create similar templates for other parts of CU? The disadvantage of this way would be little more code to fill, but all entries in particular part of CU would have similar layout. Following this idea Template:DistributionBox is currently being developed. You can see preview on Community_Update_Draft in Distribution section.

  • Currently there is voting ongoing on community mailing list. Come on in and vote for your favourite template, or leave comment here!

Community Update releasing process

And last but not least...In fact it is pretty important: never copy/paste contents of CU to release the page! Instead always use "move" button on top of wiki page. This "button" is intended for this action and by using it you save all editions and contributions history.

Mailing list interface

Often there is a need to provide link pointing to discussion on a mailing list. Services providing web interface to mailing lists (like nabble.com) were reported many times to break discussion threads in mail clients. Remember, mailing lists were designed to be used with mail clients, not with web forums. If you need to provide link to discussion on mailing list for those who are not subscribed, use mailing list archives.