Membership in PARPG development

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Established workflow.png This article covers an established workflow.

Established workflows have been discussed among and agreed upon by the development department(s). They should serve as documentation how these workflows are successfully utilized in the project.

This article explains why membership in open source projects usually works quite different compared to the traditional company world. Furthermore it explores the different roles in PARPG development.

Contents

Disclaimer

If you've contributed to open source projects in the past, this article might seem like an old hat to you and is just stating the obvious. In this case: simply skip it. The purpose of this article is to explain how membership works to people who haven't contributed to open source projects in the past. As PARPG is a game project, it attracts a larger number of newcomers who don't have a programming background and might not be familiar with the OSS philosophy. This article was written to give them an idea how things work around here.

There is one video that might be able to transport the message of this article far better than the article itself. We recommend to watch it to everyone who is either new to open source projects or is intestered in learning more about the way they work. The video itself is quite entertaining as well, so we encourage you to to check it out: How open source projects survive poisonous people

Open source vs. the traditional company world

This section explores how open source development is different to membership concepts in traditional companies. Keep in mind that we'll exaggerate and paint things in black and white to get the point across. It's not how development works in all open source projects and there are quite some companies that apply open source philosophies.

Nevertheless, most open source projects are different to traditional companies in these regards:

  • You're working with unpaid volunteers
  • Due the nature of the project, developers can't work on an open source project full time; that means you're operating with limited resources in that regard
  • Developers are spread across the world and most of them are not in the same time zone; this mean that almost all communication happens online
  • Membership itself - basically the question: "Who belongs to the projects?" - is very vague/blurry; open source makes it easy to get involved, but it also makes it easy to disappear again
  • Due the nature how membership works in open source projects, fluctuation of developers is quite common; that's a problem companies have to deal with as well, but large fluctuation in OSS is even more common, especially for community members and contributors (for an explanation of these terms, see below)
  • While traditional companies often follow a top >> down management model, most OSS projects are bottom >> up; there is no clear hierarchy and you often have no well defined direct supervisor in open source projects

Titles vs. roles

Traditional companies often rely on a formal membership by title concept. Your position in the company is defined by your formal title. PARPG (and some other OSS projects) work different in that regard, as they're relying on informal membership by role concepts. It doesn't mean that these roles are written down for every OSS project, but these roles often exist in the project reality. This article explores the role concept to give you a better idea what kind of expectations are associated with these roles in terms of commitment to the project.

Trust is the currency of PARPG development

Trust is the currency of PARPG development. You build up trust while contributing to the project in various ways:

  • Participating in brainstorming at IRC and forums
  • Helping the project flourish and grow by spreading the word about it and/or recruiting new developers
  • Improving existing code/assets/documentation that is already in place or producing entirely new code/assets/documentation
  • Fleshing out proposals in your specific field of interest
  • Improving workflows for the different development departments or establishing new ones
  • Leading by example in your department
  • Maintaining the process philosophy of your department and/or defining the creative vision of the game in your field of work

Are some developers more equal than others?

No, developers are not more equal than others. While there are informal roles the different developers play in the project, these roles don't make you more equal than others per se.

In reality however, some developers are actually more equal than others. They've contributed to the project over a longer period of time, they've proven that they're willing to engage in substantial, hard and time consuming work. They've proven that they can not just talk the talk but also walk the walk. Newcomers won't be looked down upon in PARPG. They're are very welcome and their feedback will be taken seriously. But obviously developers who have built up a lot of trust among the other developers by contributing have more say in the direction of the project than the new guy who just showed up. It's simply the way it is, so we won't lie about it.

The four roles in PARPG development

These roles are not meant to create a hierarchy of developers, but to give you a better idea what kind of expectations are associated with each role. Everyone is free to act in the role that suits him/her best. There is one fundamental rule of thumb though: don't expect others to contribute in a more substantial way than you're willing to do.

Community member

Membership in open source projects is blurry and vague. Whenever somebody shows up in IRC or at the forums, they're starting to become part of the PARPG community. They usually start by asking questions and getting more familiar with the game and the project while doing so. Community members prefer to brainstorm and toss around ideas. That's a perfectly valid way of contributing to the project in a minor way.

What community members should avoid to do is to demand the implementation of substantial changes to the game or the project in a short period of time. This project is years in the making and change simply takes time. Suggestions are more than welcome but if they're worded in a very demanding tone, they usually insult the status quo and all the work that was required to get there. Simply asking a question (Have you thought about ...) instead of demanding change in an aggressive way (Your project won't go anywhere if you don't ...) often does wonders. Developers are far more willing to listen to suggestions if they're worded in a reasonable way.

Contributor

Some community members might consider to contribute to the project in a more substantial way down the line. They might spread the word about PARPG, send in code patches or new assets or improve the project documentation at the wiki. By actually contributing in a more substantial way than just tossing around ideas, they have become contributors to PARPG.

While we're trying our best to help contributors to get started, focusing on other aspects of the development process can have a higher priority. Reviewing sent in patches and assets can take quite some time, so please be patient and don't demand code/asset/documentation review in an aggressive way. We're having an eye on all sent in contributions, but they're not the main priority of developers and lead developers when working on the project.

Developer

As you build up trust in the community, your contributions to the project won't go unnoticed. At one point the other (lead) developers will sit together and discuss offering you commit access to the version control repository. That's basically the formal definition of being a PARPG developer: having version control access. In the past others have reviewed your contributions before they were commited into the version control repository. As developer you've gained enough trust that your contributions will be reviewed after they have been commited by you.

Being a developer means to be commited to the more substantial parts of the game development process. This includes writing proposals in your specific field of work.

Lead developer

While most developers are primarily interested in working on the game itself, lead developers are willing to help coordinating the project. They set the direction in their field of expertise, they monitor the workflows of their departments and apply changes where necessary to ensure a smooth ride for the other developers in their field of work. They're leading by example. They maintain the process philosophy of their department (especially for the process heavy departments: programming & project management). They define the creative vision of the game in their field of work (for the creative departments: audio, graphics, game design, writing).

Personal tools