How Does It work?
We are developing a cooperative project management system. It can be thought of as a living process which will adapt to changes and new ideas over time. We utilize a system of Work Packages which exist in our web project management system. These work packages are the building blocks of the development process.
Every work packages has stages of evolution which they go through. These are the Stages of Development. For example, a new work package begins its life as a Suggested Work Package. Eventually it will mature through different phases of development until it reaches the stage of a Released Work Package. We explain these stages further down in this document.
Every idea, asset, program, and so on take their first and last breath of life as a Work Package. The life cycle of these work packages are manipulated by different roles community members play. These roles are listed below.
Six different levels of participation.
There are many different ways you can be involved with our project and the development process. Below we listed the six different types of participants.
Community Members are the most important members of the project. They are the ones who participate in our forums, try out new releases, and tell their friends about us. Without Community Members our project would be a lot less rewarding.
Moderators manage the community and make sure everything is running smoothly. They do things like police the forums, answer emails, post news updates, and conduct general public relation duties which arise over time.
Administrators makes sure the back end infrastructure is working as it should. These community members maintain things like the servers which host the content, manage communication systems such as our email, and maintain the software packages which run things like this forum.
Contributors create the content for the project. In order to be considered a contributor one must have Submitted at least one Accepted Work Package or be in the process of Developing a Work Package. If you meet this criteria you are considered a Contributor and will be included in the Project Developer Credits. Please contact an Organizer so they may update your credentials within the system.
A Committer is a community member which the Organizers have granted Git Push and Project Management privileges to. These Committers are the Contributors which have completed enough work packages to be considered serious developers of the project. The amount of work required to become a Committer varies. Generally, Organizers notice which Contributors work the most and will ask them if they would like to become a Committer. At this point they are trusted with the ability to Push content to the Git Repository and manage more of the day to day tasks.
Organizers guide the direction of the project. They have access to our project planning system and use it to set goals, objectives, and write design documents. The organizers are the dedicated community members which have the largest sway in the direction of the project. These members have a proven track record and have helped immensely with accomplishing project milestones and completing the necessary tasks to keep the project running smoothly. Organizers exemplify both dedication and professionalism and will make or break the success of the project. If you are interested in becoming an Organizer we suggest you write many well thought out Suggested Work Packages and participate heavily in the development process. We notice the community members with the vision and clarity necessary to be an Organizer. Great gameplay ideas are common. The vision to make those ideas reality and the pragmatism to keep the vision attainable is rare. Organizing is not as much fun as it seems and may feel more like a day job than a hobby.
Work Packages: What are they?
Work Packages are the building blocks of the development process. They are the single units which function in the game. For example, here are some Work Packages: a gameplay idea such as capture the flag, a set of footstep sounds on metal, a simple med kit mesh, a brick wall texture, a working turret mesh with material sounds and animations, a blueprint, a C++ plugin, a new weapon mesh, a drone character for tablet users, and so on. Anyone is welcome to submit a Suggested Work Package. Below is the basic framework of how this process works.
Work Packages: Stages of Development
Work packages will go through various stages of development during their lifetimes. Many work packages will never make it past the category of Suggested and few will make it all the way to the Released status. We define each stage of development below.
Suggested Work Packages are Work Packages which a community member has submitted to our project page which indicates an idea for a feature or asset. Any community member can suggest a Work Package. Organizers follow the Suggested Work Packages and decide if they will be accepted or not. Suggested Work Packages are discussed and the organizers encourage a vibrant debate over suggestions.
For information on how to Suggest a Work Package, see "I Have an Idea. How Do I Suggest it?"
Accepted Work Packages are the Work Packages which are given a green light to be worked on. These Work Packages have entered their initial development phases and serious brainstorming has begun. If the Work Package is critical, a community member may be Assigned to the Package. Assigned Work Packages are frequently Scheduled with a Target Date as well.
Assigned means the task of completing a Work Package has been given to a specific person or group of persons. This makes the Work Package much more likely to be completed and also indicates that the package is more critical to the project as compared to others.
Scheduled Work Packages are the packages which need to be completed by a certain date to work within the planned development of the project. These packages are critical and are required for a specific release or targeted goal. They will be given a Target Date.
Developing means that the Work Package is currently being worked on. This means the assigned person or group is actively working on the package and are in communication with other members of the project about the development of the package.
Submitted means the Work Package has finished development and has been Submitted to the organizers for review. The organizers will evaluate the Work Package and decide if the package meets the Specifications of the Work Package and if it satisfies the project's goals. If it doesn't meet the Specification of the Work Package it will be marked as Returned and the Developer(s) will be given a reason and suggestions on how to fix the issue(s). If the Work Package meets the Standards of Quality and satisfies the Specifications, then the Work Package will be marked as Endorsed. Endorsed means the Work Package will make it into the game on a future build as a Released Work Package.
Tested means the package is being put through functionality tests. Organizers will test the package for functionality. From here the Work Package is either Returned to the Developer or is Endorsed as a Work Package waiting to be Released.
Returned means the Work Package was sent back to the Developer(s) to make further changes or improvements before the package is Endorsed. The reasons the Work Package was marked as Returned will be noted and suggestions will be made to the Developer(s) on what needs to be changed.
Endorsed Work Packages are the packages which have met the Standards of Quality and satisfies the Specifications of the Work Package. The Endorsed packages will be implemented into a future Release of the project.
Released means that the Work Package has made it into a working build of the project. The first version number where the package was Released will be indicated.
Any changes, modifications, or updates to a Released Work Package will be indicated as an Update and the changes will be noted within the Work Package.
Types of Work Packages
Each Work Package is categorized under a Work Package Type. These types reflect what kind of asset the work package is. For example, a reload sound would go under the Work Package Type "Audio." If the Work Package doesn't fit into any Type then it would would placed under "Other."
Animation | Asset | Audio | Blueprint | Bugfix | Code | Feature | Gameplay | Map | Material | Mesh | Effect | Writing | Other
I Have an Idea. How Do I Suggest it?
To suggest a work package, simply head to http://projects.metahusk.com, register an account, open the page for the project you are interested in, select Work Packages in the project's menu, then select + Work Packages located on the top right. Select the type of work package you are suggesting, name the work package's subject and write a description explaining the suggested work package. You are welcome to attach any files, graphics, or documents which help further explain your suggested work package.
To further increase the chances of Acceptance, please make sure your Suggested Work Package's subject and description are as concise, clear, and well written as possible. Vague and or unclear Suggestions are unlikely to be Accepted, Developed, and Released.
If you Suggest a Work Package which is Accepted you are welcome to contact an Admin or Organizer asking for Contributor Status.
So How Do I Start Developing?
Anyone is welcome to start Developing any Accepted Work Package. If you start Developing a Work Package, please make a note on the package and include a screenshots of your progress. An organizer will upgrade your account to Contributor status and make you the Assignee for that Work Package. The Work Package will be marked as Developing.
Depending on the type of Work Package, you may also be designated as Responsible for the package and a Due Date may be assigned. You are responsible for updating the notes, the percentage done, and the estimated time. When you complete the Work Package you should upload the file to the package page and mark the Status as Submitted and set the Percentage Done to 100%. Uploaded work packages need to follow the upload guidelines.
One of the organizers will mark the Status as Testing and test the submitted work package. In the testing process the team will decide if the package is Endorsed or Returned for further work. If it is Returned the Organizers will say why and suggest remedies.
When a Work Package is Endorsed it means it awaits inclusion in a Release. When the Work Package is released it will be marked accordingly. If the Work Package needs updating at any point then the Work Package will be marked as Update.
Work Packages Upload Process
Please follow these guidelines when you complete the development of a Work Package and are ready to submit it to the project management system.
- Work package files must be compressed into a zip or similar format.
- For the final release a naming convention should be used such as - Package Name v1.0.0
- Any changes to a Returned Work Package should follow a similar naming convention such as - Package Name v1.0.2
- Please include the working formats you used for developing the work package such as photoshop psd's and so on.
- If documentation is required to make sense of your work package then please include the necessary documentation in the file.
- A markdown credits.md file must be included. If you adapted someone else's work it must be noted and the credits must be properly attributed.
- If your work is derived from someone else's work then update the Attributed Credits in the projects Attributed Credits wiki page at http://projects.metahusk.com
Credits: How Do They Work?
Everyone who participates is welcome to enter their name in the project credits wiki page.
To enter your name on the Project Credits Wiki Page you must open an account at http://projects.metahusk.com. After you open an account navigate to the project's page and select Documentation on the left and click on Project Credits. At the top right of the page select Edit. Enter your name organized alphabetically by the last name. Anyone in the community can add their name to the project credits.
Developer Credits are reserved for those who Suggest an Accepted Work Package or who Develop assets for the project. The names on the Developer Credits are maintained by the Organizer, Committer, and Contributor lists on the project's development page at http://projects.metahusk.com
Any works a developer derives from another's work for a project must be credited in the Attributed Credits section. It is very important we properly mention the names of those we derive work from. An Attributed Credits wiki page can be found on the project's page. The wiki page has more information on the specific requirements.
Copyright Violations: please report disputes over copyright violations at firstname.lastname@example.org