- 1 Elinor Ostrom's principles
- 2 Freeic
- 2.1 Freeic legend
- 2.2 Eco
- 2.3 Will
- 2.4 Core
- 2.5 Messaging
- 2.6 Mass
- 2.7 Hierarchy
- 2.8 Production
- 2.9 Fundraising and paying
- 2.10 Decission
- 2.11 Public tasks
- 2.12 Tasks creation and management
- 2.13 Trust
- 3 Socitable legend
- 4 See also
Elinor Ostrom's principles
1. Clearly defined boundaries (effective exclusion of external unentitled parties); 2. Rules regarding the appropriation and provision of common resources are adapted to local conditions; 3. Collective-choice arrangements allow most resource appropriators to participate in the decision-making process; 4. Effective monitoring by monitors who are part of or accountable to the appropriators; 5. There is a scale of graduated sanctions for resource appropriators who violate community rules; 6. Mechanisms of conflict resolution are cheap and of easy access; 7. The self-determination of the community is recognized by higher-level authorities; 8. In the case of larger common-pool resources: organization in the form of multiple layers of nested enterprises, with small local CPRs at the base level.
- Glocalization: The project is or is willing to welcome and/or participate in more global (as in territory and thematic scope) and/or local networks.
Objectives (also named as aims, purposes, goals) are the mid-long term purposes that the project wants to achieve and the reason for it being initiated.
Free projects Objectives should be defined as accurately as posible unless the project states as an Objective not to define that sub-objective if that is not conflicting with the previously already defined Objectives.
The project hasn't a members critical mass or if it has, it has published that and the reason for a posible future merging, forking or disolution when that would be reached (see more: infinity group)
The Project has specified and available the method for new entries, exits and the privileges from members (i. e. vetos' rights, exclusive duties, quality voting, etc) if any, their temporality and the way for getting those temporary privileges.
Complaints about posible uncompliances with the free project's terms, objectives or proposed strategies have to be directed to the responsible of the conflicting content (or to the thread she opened). In case of not reaching an agreement the issue should be resolved with alternative dispute resolution mediation methodologies directed by other members that both parts agree to, before trying to raise the issue in a project voting session.
The project could punish, by discounting or ending members' rights, any behauviour that conflicts with the free project's terms and-or with the free project's Objectives.
The project has a restorative member's status defined policy, at cost on request, which should contain information about penalties for hipothetical damages.
The free project's disolution should be communicated the earlier to all their members when the free project's tasks are not being done by their assigned members.
The free project's ownership should pass to the one that better preserve the project as free project.
Fundraising and paying
The free project accepts any kind of donations in goods (including money$) and-or in whichever (skilled) time from anyone anonimously or not.
The project could specify methods of paying fees to tasks assignees in a regular or punctual way in the freest currency possible.
Everyone who has read the project objectives can propose whatever.
New decisions made out of proposals will need to be included in the Objectives definition, at the public tasks' public listing and communicated to the members if-as they have choosed.
A member can transfer his-her vote at all or for some specific issue to another member.
In the case of a technical draw at a non polytelic problem, the resolution should be choosen according to the one who better analizes the pros and the cons of his-her and the other's proposal.
The project could specify further policy on minimums for blocking proposals and quorum needed for those.
Tasks creation and management
The tasks are the the short term or regular things that have to be done for maintaining and getting closer to the project Objectives.
Tasks are created by the people's suggestions and have to comply with the project Objectives. The new proposals for project tasks can be done by anyone through all posible ways at cost on request, starting by adding in the tasks listing the need of a more proper communicating of new tasks (i.e. e-form, paper writing, voice, etc) if the project is not yet offering such facilities.
Project members have the rigth to see and be directly informed of new tasks suggestions and refuse them to be added to the tasks list.
The free project is or tends to manage tasks according to:
- Minimizing tasks' dependency on specific assignees.
- Categorize tasks
- Minimize the basic tasks for doing more developmental tasks.
- All tasks are public tasks
Categorizing tasks should provide guidance for volunteers and clarity to the project way of doing.
Accepted and refused tasks
- Active tasks. Action proposals that have been aproved as maintaining or developing the project.
- Assigned task. Assignee could drop her assignation anytime and should inform the public about their volunteering scheduling and should work on standarizing the practices for doings the specific task (i.e. protocols, forms, roadmap in case the crowd comes, etc).
- Unassigned tasks. Doings aproved by the project but without any volunteer willing to be assigned yet.
- Postponed tasks
- Closed tasks
- Done tasks are tasks that acomplished what its own objectives
- Postponed tasks are task that was active that now it is not because is being reviewed
- Cancelled tasks are deleted tasks from the tasks list because there has been a change in the project objectives
Regular tasks are the doings that anyone can do with requesting permission to the project that nor needed to be published as projects tasks. (i.e. tell a mate about the project, link us, send us cheers, etc)
Basic and development tasks
- Basic tasks are what have to be done for maintain the project alive.
- Developmental tasks are the tasks that are getting closer to achieve the Objectives.
Public and private tasks
- Public tasks is a listing of things that need to be done inside a group - project - community for improving it according to their objectives which everyone, being a member or not, is allowed unrestrictedly to do it - them. Public tasks listing should be available to the public in all posible ways at cost on request.
- Private tasks. Tasks just available to be a assigned to some member of the project.
- Not published tasks. Just visible for members
The tasks priority level could come as a result of the group strategy specification process. That specified priority should be used just an additional advice, and should never be used for difficulting volunteering working on low priority or unassigned tasks.
Tasks assignation and cancellation
Assignees should propose to get on the task.If there is a concurrent competing case for being a task assignee, the task(s) should be assigned to the one who is less engaged in other project's tasks already; less fees is asking for; has a higher restorative status in the project; has more available time and-or resources for accomplishing or managing it the quicker or; has suggested the task.
When a task that is being commited or coordinated by some volunteer is willing to be cancelled o postponed, the information has to be provided to the commiter or coordinator prior cancellation or postponing for him/her being able to discuss that. Once a final decission of refusing or closing a task is reached, the arguments for deciding that should be provided to the public and kept documented during a reasonable time.
The Accesibility parameter estates the more or less difficult is being a user
- Useable platform (it works!)
- Decentralized (see shareful.be/good)
- Distributed (see shareful.be/p2p)
- Popularly used (see you)
See also: traceability, users mass, etc
The standards compliant subparameter of accesibility evaluates the more or less the information could be recognised and interpreted.
- No API and doesn't validate
- Almost API or validates
- Validates most of the important
- Validates almost all standards
- Validates all standards
The 'Authentication parameter estates the more or less quality and variety of authentication levels for users.
- Only verify mail
- Verify mail and other further authentication possibility
- 5 degrees of authentication (See register)
- Visibility / Permissions for each of different authenticated levels
- Custom permissions and authenticating
The 'Reputation trust subparameter of authentication estates the more or less quality tools for meassuring past activities from users.
- Comment before use
- Trust types
- Some custom fields (see evil code)
- Many custom fields (see talk)
- Standarized reparations (see footprint compensation tasks)
The grouping parameter estates the more or less groups of users can be created.
allow subgroups and groups moderated relations (related groups)
move subgroup to another subgroup
The discussion parameter estates the more or less information exchange in various topics could happen
See main page: discutable
The mediums parameter estates de more or less the information can be exchanged with variety of formats and platforms.
The federation paremeter estates the more or less importable and exportable the exchanged information could be.
See main page: federatable
I like at a third party
Admin import / export
Advanced admin import / export
User import / export
User advanced import / export
New node ease
The privacy paramenter estates the more or less options for ceratin visibility for the exchanged information.
Edit / delete content
Edit / delete user
Permissions per fields
Custom user permissions groups
Encrypted private messages
Post encryted content
The content aggrupation parameter estates the more or less the exchanged information can be related and customly hierarchized.
site wide categories
site wide categories per content types
site wide categories per fields
relate tags to tags
moderated tags relations
relate tags and categories
move tag to subcategory
sharing ontology with third parties
The 'Inteligent ontologies subparameter of content aggrupation estates the more or less accuracy of wanted content dinamickly displayed to the users (you might be interested in, etc).
- Admin create direct taxonomies relations
- Crowdsourced relations
- Admin create weighted relations (see you may be interested in)
- Users create weighted relations
- Implicit activity relationing (see talk)
See also botethics
The usability parameter estates the more or less the exchanged information can be easerly consulted through.
feature rich (pad, tasks, etc)
custom group presentation
The 'Terms subparameter of usability estates the more or less consistency and ease of understanding of the platform conditions of use.
- No terms
- Human readable terms (see shareful.be/good)
- Extensive human readable terms
- Lawyers backed terms
The support parameter estates the more or less robust are the background project human means that enable the exchanging of information.
The meetings have to able to be recorded, if recording and voice transforming capabilities for granting posible members' requested privacy are suplied by the requester. The project can optionally decide to make the meeting contents publickly viewable-heardable or not.
Public can silently assist to the meeting but without member's rights further than what the project optionally decide. They are not granted to be able to attend the meeting if they have not communicated their willing to the Moderators within a reasonable time in advance for them being able to find a bigger place where everyone could comfortably fit in.
Issues raised for being decided at a meeting have to be comunicated within 3 days in advance to the project's members. Every member has the right for postponing the decision on it if not communicated this way, unless the issue has been raised by an accident and is considered to be urgently resolved due to an important loss if not.
New one(s) have quality voting rights for project's consensed polytelic problems resolutions.