-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This is a listing of all of the so-called "top level objects" in the site. These are basically what a user would think of. They are the nouns of the site.
The project is the main entity in the entire structure. Almost all other entities are ultimately under a project.
Projects are designed to go through several different phases, though every project may not go through every stage. In general, a project only moves from one stage to another by direct action of the project owner. In general, a project only moves "forward," though it can move backward if you really want to.
The statuses are as follows:
- Secret - This project is only visible by project members. Absolutely no information can leak out, ever.
- Private - The project can be searched for, but cannot ever be mentioned to users that haven't suggested existing knowledge. This status may be removed upon further reflection.
- Teaser - The project is designed to be found (ie, I am allowed to make it a featured project). Only information marked as public by the project admin will ever be public. This will usually be files (I imagine usually images) but could also be a list of the people involved in this project, etc.
- Public - All information about the project is visible, including internal conversations, etc. I will be encouraging (but not requiring) projects to enter this state after the game is over, to share more project information with the masses.
- Open - All information about the project is visible, and somewhat editable. Conversations can continue, etc. I only ever expect Velour to be in this state. I may, upon further reflection, disallow anyone but me from setting projects into this state.
A project has the following attributes:
- Name - This is the real name of the project. There is no reason to be secretive in this name. It will only show up if you are in the project, or the project is in a state of public or above.
- Teaser Name - This is the name that will be visible if you are not a member of the project and the project is in status of private through teaser. This can be a playful secretive name if you Name gives away too much.
- Description - This is a short "bio" for your project that will appear on the landing page for non-members and if you become a promoted project.
- Icon - Your raw icon for this project. There are a number of images generated from this image, but on the raw project entity we only store the base image.
- Created - When this project was created.
- Edited - The last time this project was edited.
- Creator - The person that created this project.
- Owner - The owner of this project (same as creator unless it has changed hands).
- Roster - This is a list of all the people working on this project, and what role(s) they fill. This relationship is somewhat hairy code-wise and needs to be better planned out.
Projects can be created in exchange for One Point. This point does not have to come from the owner of the project. Due to the ability to earn points in exchange for being good members, I want members to be able to donate a point toward their favorite PM. To make this work, we need to not require that user to know anything about the resultant project. Of course, we should encourage the member to get a reward for their donation.
The wiki is also a base class for the viki, so care must be taken to make it flexible. It should be functionally very similar to the wikis that we know and love, though it does not have to be the same underneath.
Wikis are pages that can be edited by anyone and contain some sort of markup. This is incredibly incredibly similar to a page that cannot be edited by anyone and contain some sort of markup. For that reason, I am aiming to reuse the wiki code for everything textual. The next natural progression is to make the interface for creating a True Wiki and a Fake Wiki the same. And in fact, that is what I shall do.
When you create a new document, you are given the option to make it a Community Document (perhaps get better terminology). If it is one, anyone on the project can edit it. If not, only you can.
Both kinds support conversations as comments below the document. For a community document the planned use case is similar to how Wikipedia technically has a conversation on every Wiki page. If you do not turn on community mode, of course it is the only way that users can point out flaws, etc.
We need some kind of tokenizer/diff code that we can reuse in order to give the users a concise description of what changed. This can also be used for the History view, which is an awesome killer feature.