Difference between revisions of "Activity Library/Editors/Policy/Non-Technical"

From Sugar Labs
Jump to navigation Jump to search
(categorize)
 
(26 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Some points that could be considered during activity review(maybe some of activities should be removed at all).
+
<noinclude>[[Category:Policy]]</noinclude>
 +
=== Who can be an editor ? ===
 +
Any sugar learner should and can be an editor of the Activity Library,
 +
we only advise that the editor can't be the developer of the activity, this is true for non-trusted activities. (see definitions bellow)
 +
 
 +
* ''Trusted Activities''
 +
These are activities that don't need an editor approval for publicize new updated versions.
 +
 
 +
* ''Not-trusted Activities''
 +
These are activities that need an editor approval in order to publicize new updated versions of the activities
 +
 
 +
Maintained activities are entitled to be trusted, and all activities that fulfill technical and non-technical policies can be trusted.
 +
 
 +
== Removing, reviewing, sandboxing activities ==
 +
 
 +
Some points that should be considered during activity review, some activities might be entirely removed.
  
 
=== Reasons for removing ===
 
=== Reasons for removing ===
  
* inappropriate(violent, sexual, subversive content) content
+
* Inappropriate (violent, sexual, subversive) content
* non-FOSS licence, any restriction for essential(for education, some people think, essential for  
+
* Inappropriate license, see Oversight Board [[Oversight_Board/2009/Meeting_Log-2009-12-11#non-FOSS content|meeting notes]] for details.
other cases too:) behaviour, free to run|study|redistribute|change
+
 
** code should conform [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses FSF GPL compatible list]
+
=== Reasons for keeping or moving to the Sandbox ===
** the rest of content should one of [http://creativecommons.org/licenses/ CC] licences
+
 
* (?) activity is just bundled application which already (well)packaged in various distros
+
Activities that are experimental are kept in Activity's Library sandbox (i.e., only registered users can download them).
* ...
+
 
 +
* '''Any confusion with already-published activities'''<br>
 +
 
 +
'''Action''': Make the difference more clear, by obvious renaming, providing notice in the description, or not launching activity, etc.  
 +
 
 +
* '''Buggy activities'''<br>
 +
If the activity is proving to not start or is having serious functionality problems, it should be moved to the sandbox or removed.
 +
 
 +
'''Action''': Contact the maintainer or Developer to notify them of the issue.
  
=== Reasons for retain in sandbox ===
+
** At the same time we should stimulate experiments, changing existing activities and, very importantly, sharing results of these experiments. A new ASLO code base might support having several implementations ("forks" might be too hard a word for them) of the same activity. Need to think how this can be achieved.<br>[[User:Alsroot|alsroot]] 07:32, 25 October 2010 (EDT)
  
* (?) lack of educational value<br>arguable, it could be something useful for user environment e.g. UsbCreator<br>'''A''': add such value :)
+
* '''Obvious misuse of categories, e.g., FireFox activity in Teaching tools'''<br>
* any confusion with already existed activities<br>'''A''': make difference more clear, obvious renaming, making notice in description etc.
+
'''Action''': Contact the uploader to clarify the category choice.
* ...
 

Latest revision as of 10:12, 1 November 2011

Who can be an editor ?

Any sugar learner should and can be an editor of the Activity Library, we only advise that the editor can't be the developer of the activity, this is true for non-trusted activities. (see definitions bellow)

  • Trusted Activities

These are activities that don't need an editor approval for publicize new updated versions.

  • Not-trusted Activities

These are activities that need an editor approval in order to publicize new updated versions of the activities

Maintained activities are entitled to be trusted, and all activities that fulfill technical and non-technical policies can be trusted.

Removing, reviewing, sandboxing activities

Some points that should be considered during activity review, some activities might be entirely removed.

Reasons for removing

  • Inappropriate (violent, sexual, subversive) content
  • Inappropriate license, see Oversight Board meeting notes for details.

Reasons for keeping or moving to the Sandbox

Activities that are experimental are kept in Activity's Library sandbox (i.e., only registered users can download them).

  • Any confusion with already-published activities

Action: Make the difference more clear, by obvious renaming, providing notice in the description, or not launching activity, etc.

  • Buggy activities

If the activity is proving to not start or is having serious functionality problems, it should be moved to the sandbox or removed.

Action: Contact the maintainer or Developer to notify them of the issue.

    • At the same time we should stimulate experiments, changing existing activities and, very importantly, sharing results of these experiments. A new ASLO code base might support having several implementations ("forks" might be too hard a word for them) of the same activity. Need to think how this can be achieved.
      alsroot 07:32, 25 October 2010 (EDT)
  • Obvious misuse of categories, e.g., FireFox activity in Teaching tools

Action: Contact the uploader to clarify the category choice.