Proposal to Modify the Wiki

From OpenLuna
Jump to: navigation, search

Contents

Generate an Outline

by Sbharris

I know outlines are boring. You were supposed to do one every time you did an essay or report. And you thought the brand new database properties of the Wiki were going to get you out of having to think of that. Wrong.

The Wiki database is a marvelous hyperlinked thing, in which every node (wiki) can be hot-linked to any other. BUT, getting into this can get you into a spaghetti of wikis with no particular order, and navigating through that can be like navigating the web. Except with no search engine like Google to help. You don’t want that.

Failing this, somebody has to start by putting down a VERY broad outline of trees of subjects the Wiki dbase is about, and this ends up being in semi-outline form, with categories and sub-categories and sub-sub categories. There’s no escaping that. It’s how we classify living organisms, for example. It’s a sort of taxonomy of the wiki-dbase you have. Right now, this Wiki-dbase for Openluna has absolutely no such structure.

But once this is done, a general order can start to be imposed on random wikis, by many mechanisms, which you will be familiar with, if you’ve worked on Wikipedia.

One major one is category pages. These can be created any way you like, and other pages can be mentioned on them by simply adding a [[category:X]] tag to the bottom of the page. When you create the category page, all the subpages with the tag show up there, in alphabetical order.

Within articles, besides the normal hyperlinks to other wikis (which you make with double sets of brackets, like [[this]]), the way to link to major “tree” subjects is with “main articles” and with articles in a “see also” section of internal links to other related wikis that haven’t been mentioned in the main article. The “main article” links are when you want to go into more detail, so you name a subarticle which is too long to be included in the main article. Then you leave a summary of it behind in the main article, and thus you end up with a tree of more and more detailed articles, which you can move naturally through while reading. For more on this, see the wikipedia article on summary style: http://en.wikipedia.org/wiki/Wikipedia:SS.

In any case, first we need an outline, and I can’t do that myself. I need your help. I’ll put up at the end of this, and you can start making suggestions. These in turn can be turned into category pages, and so on. I’ve even done a few category pages, like [[Category:Launch Vehicles]] to show how this is done.

Again, this is ONLY to help the new reader to get into the thing. It really does not impose much in the way of “needing to do things this way or that” on everybody else. You can still link any wiki to any other wiki. But this way, the newbie can find his or her way around. Sbharris 22:40, 5 February 2010 (UTC)


Example Outline

EXAMPLE OUTLINE for Openluna.com Wiki (feel free to change in any way you like)

I. Openluna project

A. Program introduction
B. Instructions for new volunteers
C. Guidelines for development

II. Openluna Wiki

III. Mission to the moon (Here we talk about anything about the general mission which isn’t covered below in specifics)

IV. Funding

V. Modular pieces of equipment

A. Launch vehicles
B. Lunar landers
C. Lunar surface base (Outpost)
1. Space suits (Lunar surface suits)
2. Rovers & surface transportation
3. Etc.
D. Earth return systems

VI.Technologies

A.Power systems
B.Life support
1. Air
2. Water
3. Food
4. Waste
5. etc
C. Radiation shielding
1.Normal surface conditions
2.Solar Flares
3.Etc.
D. Lunar resource recovery
1. Water
2. Using soil
3. Fuel

VII. Crew and human factors

VIII. Mission Duration and re-supply

IX. Mission science

X. Other problems

XI. Connections to future Mars mission



- Below is an older proposal -

Introduction

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.
  • 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).
  • Sub-portals:
    • 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.


Standardization

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.


Discussions

Please feel free to discuss this new proposal, clarify any misunderstandings and add further information/ideas as needed.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox