Difference between revisions of "Features/License selection in Journal"
| Line 30: | Line 30: | ||
== Benefit to Sugar == | == Benefit to Sugar == | ||
| − | + | I believe that it is wrong to have a learning platform for creating content that ignores the licensing issue. It would be of benefit to our users to be introduced to concept and practice of licensing and this feature provides that mechanism. | |
| − | |||
| − | |||
== Scope == | == Scope == | ||
Revision as of 19:09, 1 December 2009
Summary
While we encourage learners to create and share their work, we provide no mechanism for them to assign licenses to their work. This feature introduces a license field to the Journal to give the learner an opportunity to assign a Cc license to their work.
Owner
- Name: Walter Bender
- Email: <walter AT sugarlabs DOT org>
Current status
- Targeted release: (0.88)
- Last updated: (DATE)
- Percentage of completion: XX%
Detailed Description
Based upon the work of Jon Phillips at www.creativecommons.org, we propose to add a widget to the Journal that lets user choose a license for their work. See this old ticket along with screen shots: https://dev.laptop.org/ticket/3529
We'll have to reexamine Jon's original patch and look at some tickets that were at the time (2 years ago) blockers: [1] [2] [3]
There is an old thread on this feature as well.
Benefit to Sugar
I believe that it is wrong to have a learning platform for creating content that ignores the licensing issue. It would be of benefit to our users to be introduced to concept and practice of licensing and this feature provides that mechanism.
Scope
What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?
UI Design
Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.
How To Test
Features/License selection in Journal/Testing
User Experience
If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.
Dependencies
What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, does your feature depend on completion of another feature owned by someone else or that you would need to coordinate, which might cause you to be unable to finish on time? Other upstream projects like Python?
Contingency Plan
If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If your feature is not completed in time, we want to assure others that other parts of Sugar will not be in jeopardy.
Documentation
Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.
Release Notes
The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.