Proposal to Modify the OpenLuna Wiki
This is a proposal to reorganise the OpenLuna wiki. The aim of the suggestions made here is to:
- organize the OpenLuna community
- identify and organize the different functional areas within OpenLuna
- introduce a simple system to create tasks and work packages
- consider the introduction of some form of standardization.
OpenLuna consists of a number functional areas (e.g. engineering, ground operations, publicity, etc.). Each of these functional areas could be allocated a portal on the wiki where work on that specific functional area may be carried out. Each portal would have a head who will lead and manage the portal (and hence the functional area). For example, the engineering portal will be headed by the Chief Engineer and the finance portal will be headed by the Chief Financial Officer.
Each functional area could then be divided into projects or programmes and then subsystems or work packages. Each subsystems would then be divided into various tasks. The work packages and/or tasks may be allocated sub-portals as necessary.
As for the Open Luna community, they maybe grouped as Core Group and Volunteers. The Core Group will consist of those members who must remain with Open Luna for extended periods of time. Long term commitment will then ensure the smooth fulfilment of all duties. The volunteers are those who may work on tasks for short periods of time and then leave if they so wish.
Below is a more detailed description of what has just been mentioned.
The OpenLuna Community
Members of OpenLuna maybe grouped as Core Group or Volunteers.
- The Core Group: members of this group will consist of the project manager, heads of each functional area, subsystem leaders, and any member who must remain with OpenLuna for an extended period of time. All members of the Core Group must remain with OpenLuna for a long period of time to oversee completion of large portions of their work. Since it may take a while to find replacements for these individuals, and taking into consideration the key role they play in the smooth progress of each mission, it is strongly advised to recruit people who are willing to commit for long periods of time.
- The Volunteers: these are people of the public who are interested in working on OpenLuna tasks. They do not have the obligation to commit themselves to OpenLuna for extended periods and may leave at any time. Ideally, they should leave after the completion of their task(s).
Functional Areas and Wiki Portals
The portals feature of wikis is of great benefit to the OpenLuna community. For the purposes of OpenLuna, it is akin to different departments within an organisation where each portal is the working space for a functional area. The functional areas that have been identified so far are:
- Project management: this is where the Core Group would meet and agree on major issues affecting the mission(s) or the Open Luna objectives. It is also the space for the Board of Directors to interact with various functional areas of Open Luna and follow the progress of duties and tasks.
- Engineering and Ground Operations: as the name implies, this area is for all engineering problems to be resolved and for all vehicles/machines to be designed. It is also the working space for ground operations and its required infrastructure.
- Finance: handles all matters of money and funding. Allocation of money to the various functional areas will also be the responsibility of Finance (with consultation with project management).
- Public relations: will deal with all matters relating to publicity, marketing and the press.
- Science: identifies the scientific data to be obtained from each mission. Will also liaise with Engineering to select or design the necessary hardware for each mission and how information will be collected and processed.
- Education: will be the functional area to disseminate information to the public and the scientific community. Reaching out to schools and universities is a particularly important aim.
Each of the above functional areas will have a dedicated portal where all the required work is executed and relevant discussions carried out.
In the future, other functional areas may arise, namely: training (for astronauts and crew) and manufacturing (to liaise with manufacturers).
Organization of Each Portal
Each of the above mentioned portals will be further divided to facilitate the design and completion of the mission. This method of organisation follows a waterfall method which will help identify the various components in each functional area and should greatly simplify the allocation of tasks.
Portals/functional area should be divided into:
- projects or programmes: this will identify the major projects within a functional area (e.g. launch vehicle, lunar lander, etc)
- subsystems or work packages*: projects would then be divided into subsystems/work packages which deal with one specific area of the project (e.g. for the launch vehicle, there will be a power subsystem, propulsion subsystem, etc.)
- tasks: subsystems would then be further divided into tasks. This is the smallest possible division which will deal with the tiniest details in a project.
If a subsystem is not too complicated, all tasks may be finished by one person. More complicated subsystems will require one person per task or even one team per task, in which case one person will act as team leader for the task. The subsystem leader should be chosen from the individuals working on the subsystem.
'*NOTE: subsystem and work package will be used interchangeably. Since 'subsystems' are usually associated with engineering systems, the name 'work package' will also be used to refer to division of duties in other functional areas.
As for the information in each portal it should include:
- Portal main page:
- The main portal page should include an introduction and general description of the functional area (what the functional area does, achievements, etc.).
- It should also include news and updates specific to the functional area.
- The portal main page will have a link to a page explaining the organisation of the portal very clearly and regulations that must be observed while working on work packages and tasks in that specific portal (see Standardization below).
- It will include a list of incomplete tasks or work packages.
- Finally, it will also contain link(s) to resources helpful to the members working on tasks in the portal. Resources may be academic and scientific papers, national/international regulations, software, etc.
- Portal main page:
- A page including all projects and their subsystems:
- This page will include all the subsystems or work packages included under the current portal and will be linked from the portal main page (see above).
- Subsystems and tasks must be presented in bullet points to clearly see the divisions with brief explanations.
- Each work package should link to a sub-portal dedicated to that specific work package.
- A flowchart depicting the projects, subsystems and tasks must also be included (as an image).
- A page including all projects and their subsystems:
- This will be the working area for each subsystem.
- Members working on the subsystem will 'gather' in the sub-portal to discuss issues and progress and complete tasks.
- The sub-portal main page should be similar to the portal main page with information, updates, new tasks, news, etc.
Work Packages and Tasks
When creating and announcing a task or work package, it must be accompanied with a description as follows:
- duties to be performed
- any prerequisites that an individual must have to successfully complete the task (e.g. work experience, a certain programming language, etc.)
- number of people expected to work on the task
The task should be placed on the work package sub-portal and on the portal main page for all to see and access.
Updating the Current Wiki to the Proposed Wiki
Members in each functional area shall be responsible for migrating all current wiki pages to the new wiki portal specific to their functional area. As an example, all members working in finance are to create the finance portal and migrate all necessary pages from the current wiki. Unwanted pages may then be deposited in an archive arranged alphabetically or by subject.
In large projects, especially in those where members come from different countries, each person may perform a task in a different way. To give a trivial example, engineers from one country may use the metric system while those form another country may use imperial measures. In order to maintain a standard and to avoid any possible confusion, each functional area must produce a document detailing all guidelines, technicalities and standards to be followed within that specific functional area. This document should be easily accessible from the respective portal. Also, any issues regarding quality control or quality assurance should be covered.
Another document must be issued by the project management stating all the guidelines to be followed by everyone working on Open Luna regardless of their duties. This document will detail matters such as the over all organisation, the overall architecture of the mission(s), how to use and edit the wiki and other relevant information. Preferably, disciplinary and grievance procedures should also be discussed. This document should be accessible from the main page and from all portals.
Please feel free to discuss this new proposal, clarify any misunderstandings and add further information/ideas as needed.