Difference between revisions of "Activity Library/Editors/Policy"

Revision as of 08:00, 24 October 2010

NOTICE: This page is a draft in active flux...
Please contribute to these contents and discuss issues on the discussion page.

Technical policy

All technical checks will happen automatically while uploading activities.

Non-technical policy

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.

Resources

Original AMO policy

@@ Line 1: / Line 1: @@
 {{TOCright}}
 {{draft}}
-== ASLO auto checking ==
-* Unique ''bundle_id'' activity.info field value
-* Unique ''name'' activity.info field value
-* ''license'' activity.info field value has short names that conform fedora good licences lists: [http://fedoraproject.org/wiki/Licensing#Good_Licenses software], [http://fedoraproject.org/wiki/Licensing#Good_Licenses_2 documentation] and [http://fedoraproject.org/wiki/Licensing#Good_Licenses_3 content].
-* Activity version is an integer number
-* Check if activity has correct link to bugs tracker
-* Activity version has release notes
-* Hide activity name field and fill it in from uploaded .xo (for all locales)
 == Technical policy ==
-* Check that activity runs on declared Sugar Platforms.<br>Major sugar environments are [[Development Team/Packaging]]
+All technical checks will happen [[Platform_Team/Recipe_Lint|automatically]] while uploading activities.
-* (could be postponed until v2 of Policy) If activity has binary blobs, check it on:
-** x86 architecture
-** x86_64 architecture (looks like we have x86_64 only for SP-0.84+)
-* If activity entirely(not just minor glitches like screen resolution) depends on hardware/software properties of particular environment(XO for example), this activity can not be pushed to the public and should be left in [[Glossary#Experimental_activity|Experimental]] stage. In that case editors could collect these activities in collections e.g. "Experimental XO activities" until they are fixed to run in common environment which satisfy Sugar Platform specification.
-* Check it there is a component for activity on [https://bugs.sugarlabs.org/ bugs.sugarlabs.org] (or whatever was set as bugs tracker), if not, ask uploader about maintainer and create(request for creation) one
-* For all bugs, that were found during review, create bug tickets
 == Non-technical policy ==