Talk:Community Updates/2009-08-19

From Openmoko

< Talk:Community Updates(Difference between revisions)
Jump to: navigation, search
(Please do basic spell check. Firefox underlines words for you in red. Also fix links - you don't need underlines.)
(-Released.)
Line 1: Line 1:
==Welcome==
+
Released.
Here you can get a clue on how to contribute to Community updates, while conforming to wiki editing guidelines. You can take a look at [[Community Update Draft]], to have a feel how coming update draft would look like, if we follow all these standardised wiki guidelines. Feel free to discuss here about this topic, maybe we achieve consensus before next CU. 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:<BR>
+
<pre><nowiki>
+
{{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
+
}}
+
</nowiki></pre>
+
If application/something else has its own wiki page, put its name in double square brackets:
+
 
+
==Links==
+
Keep in mind the difference between [http://meta.wikimedia.org/wiki/Help:Link#Interwiki_links internal] and [http://meta.wikimedia.org/wiki/Help:Link#External_links 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 {{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 formatting]
+
 
+
You might wonder which 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==
+
Many wiki editors do not fill in "Edit Summary" filed under "edit" box. This summary becomes very handy when it comes to later version comparison. 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.
+
 
+
It is also quick and quite good habit to prefix summary with +/-/= depending upon you add/delete/edit content.
+
 
+
==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 [mailto:community@lists.openmoko.org 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 [http://lists.openmoko.org/pipermail/community/2009-June/050363.html 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.
+
* Go to http://lists.openmoko.org/
+
* choose mailing: list http://lists.openmoko.org/mailman/listinfo/community
+
* choose Archives: http://lists.openmoko.org/pipermail/community/
+
* choose by: Thread/Subject/Author/Date
+
* provide link to [http://lists.openmoko.org/pipermail/community/2009-July/051949.html post] that in your opinion should be provided in CU.
+

Revision as of 00:29, 20 August 2009

Released.

Personal tools

Welcome

Here you can get a clue on how to contribute to Community updates, while conforming to wiki editing guidelines. You can take a look at Community Update Draft, to have a feel how coming update draft would look like, if we follow all these standardised wiki guidelines. Feel free to discuss here about this topic, maybe we achieve consensus before next CU. 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 formatting

You might wonder which 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 comparison. 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.

It is also quick and quite good habit to prefix summary with +/-/= depending upon you add/delete/edit content.

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.