|In other languages:||Português|
Guidelines on creating and maintaining a project or campaign
This project is limited to specifying the properties, templates, and forms used to create and edit project pages.
To automatically create the necessary projects, campaigns, and similar collaboration pages. Properties associate related, or relevant, information across project boundaries, templates provide the necessary markup, and forms capture data.
A project is an undertaking by several users to plan, execute, and achieve one or more stated goals.
A project may exist without members and remain dormant. There must always be a project owner, who is responsible for the project's existence. A project without an owner is considered an orphan. Orphaned projects should be adopted by the Libre Planet group until a new, or the existing, owner is found. The LP group may close an orphaned project if it believes doing so is in Libre Planet's interest.
A project owner is distinct from a project member. To qualify as a member, the owner must register with the project. Membership is restricted to registered Libre Planet users. A project may further restrict membership.
Every project must record its member status, both past and present. Users should register and deregister themselves using the appropriate forms. These forms should include a member category, or similar technique, to allow users to determine which projects they are members of, without visiting every membership page.
Where users are members of many projects, Libre Planet may request users deregister from some, if it believes they're unable to handle the workload. The determination is based on user contribution, rather than a particular number because the number of projects a person can handle will vary from person to person, and time to time.
Third parties may associate themselves as partners in a project, but not members. Partners are required to agree to the project's objectives, but not the Libre Planet's mission statement. Their access to Libre Planet's resources are limited to those provided by the project itself.
If third party members register themselves as Libre Planet users, they then lose their third party status and may not promote third party interests in their capacity as Libre Planet users. Nor may they assert their partnership status with any project when logged in as users.
Should third party members register themselves with a project as both partners and members, then Libre Planet will deem this a conflict of interest and require the users to withdraw their membership or partnership. Failure to do so allows Libre Planet, at its discretion, to terminate the users' membership and/or partnership with the project.
Projects are characterized by type, so not all projects will be run and exist as a typical project. For administration purposes, all projects will use the same forms, templates, properties, and the corresponding pages will exist in the Project namespace. Project members may create documents and resources in other namespaces, provided those pages clearly identify themselves with the project and make them accessible from at least one page in the project namespace.
All projects must be consistent with the Mission Statement, whether they are identified as a campaign, petition, rally, project, software, or group. Projects should state, or imply, their objectives with respect to one or more of Libre Planet's Mission objectives.
For administration purposes, a local user group is considered a project and therefore subject to the same requirements as all projects. This requires users create their group project in the Project namespace and define their group's membership and activities. However, the actual group must also be created in the Group namespace where it will conduct its affairs.
The Project namespace is the wiki's namespace and defined by the wiki's name. Thus, this wiki was formally known as FSF_Groups, but now called LibrePlanet. This name change caused the wiki namespace to also change from FSF_Groups to LibrePlanet and invalidated all links using FSF_Groups:. However, this same namespace can also be referred to as the Project and always refers to the wiki's namespace regardless of the wiki's name.
A project may identify sub-goals more easily achieved by a dedicated project. A project may create as many sub-projects as it requires to achieve these sub-goals. Every subproject, however, must restate which parent objectives it will achieve. The project becomes the owner of each subproject it creates.
It is possible that two or more projects may share the same sub-goal, but otherwise have little in common. Rather than each project setup their own subproject, they may create their subproject to represent their project. The subproject itself is created as a parent project and the various subprojects then register as members. This allows the project to achieve its goal, without undue influence from any other project. Each project has the freedom, through its subproject representation, to adjust its sub-goals while still benefiting from the common project.
The fate of a subproject is usually the fate of the parent project. If a project is closed, so are all its subprojects. It may happen that one or more subprojects remain beneficial to Libre Planet even when the parent project is not. In this situation, the subproject's owner becomes the parent's owner and the subproject elevated to the (now defunct) project's level. Should another project be a more suitable owner, then the project can be made a subproject of it.
The normal situation is to create subprojects as subpages of the parent project. This implies the parent project is also the subproject owner. However, anyone can own any project, so a subproject may exist as subpages of one project, but owned by another. Such an arrangement may serve both the parent project and subproject owner.
Groups should create their projects as subprojects of the group project. Futhermore, each subproject should have a corresponding subgroup page in the Group namespace. This separates the project from the group itself, so many groups may register with the project and not interfere with each other's group activities.
A group may create group projects which are additional groups in their surrounding area. Such local groups will be run independently of the main group, but owned by it. The new groups should be subpages of the main group, but its members need not include any main group member. Because the main group is the project owner, it is responsible for the subgroup's success.
Group ownership can be transferred, so a group may take ownership of another group it didn't create. Such transfers should only be done in the interest of all groups, where, for example, another group is closer to the subgroup than the current owner.
The main project page provides a synopsis, suitable for cataloging. A project catalog lists all the projects according to properties found on the project's main page.
The following properties are required to define a project:
|Project name||string||Yes||Holds the project's name, which may not be unique.|
|Project id||string||No||Identifies the project by code. This may be useful in combining related or sub projects.|
|Project type||enumerated String||Yes||A list of project types that most closely define the project. A project should only have one type.|
|Project date||date||Yes||Project's start date.|
|Project owner||Page||Yes||Name of the project owner.|
|Project group||Page||No||The parent project.|
|Project status||enumerated String||Yes||A list of project states. A project should have one state.|
|Project abstract||Textarea||Yes||A brief description of the project.|
|1:||For example [Project, Campaign, Rally, Petition, Protest, Software, Special, Other]|
|2:||For example [Open, Active, Inactive, Closed, Dormant, Other]|
The project's main page does not include membership nor partnership details. These are handled in other pages using their own forms. Links to these pages may be provided by a menubar, category, or properties. Access from the main page to membership and partnership pages is required.