The QRL Contributors

Contribution is the backbone of any opensource project like The QRL, and is emergent from the community that surrounds it.

In this way it’s important to keep things not only accessible and open, but simple, enticing, guided, cohesive, and malleable to the changing needs of both the project and how it fits into the wider cryptocurrency space.

With this in mind, we’d like to announce The QRL Contributors

This is a project that aims to open up discussions and bring in both the core and community contributors alike, and is part of our path for decentralising The QRL community network.

Practically speaking, this will allow people (QRL contributors) to work in the QRL project by collaborating on different aspects of the ecosystem from coding to design and outreach in an organised collaborative fashion. For those who aren’t contributors, the more open transparency will make it easier to follow along.

Right now, it’s open to the core contributors as well as a select group of community contributors as we squash some bugs that may arise, but we’re excited about opening this up to the wider community in the future.

Sections

• Objectives (Primary Goals, Secondary Goals)
• Overview (technical, in practice)

Objectives

Primary goals

1. Accessible: Where possible, the team and contributors should be reachable and act as ambassadors.
2. Open: Discussions and the general development of materials should be a public process that’s transparent.

Secondary goals

1. Enticing: Creating an incentive scheme that is appealing, sustainable, and produces results.
2. Guided: Structure is important to establishing a common vision within which to work. Additionally so is outlining proper scope and tracking long-term tasks for coordinating people from each working group.
3. Cohesive: Everybody has their own skillset(s) to contribute, and should be encouraged and endorsed for self-electing the way in which they’d like to participate. However, each working group should be formed with the innate ability and desirability to work cohesively with every other working group. This may be an important enough goal to have a group all on its own, as it presents special usability and tooling challenges.
4. Malleable: It’s important to remain flexible so that significant overhead is not incurred to make necessary changes.
5. Resilient: Permissions and tasks should be set up and documented in such a way that any working group or person can walk away from the project with no warning and not meaningfully negatively impact efforts.

Overview

On a technical level

The requirements for The QRL Contributors is a system that has Role Based Access Control (RBAC), specifically with the ability to have read-only environments for all visitors. Additional functionality, though not a strict requirement, is the ability to communicate and flag certain roles through mentioning them.

Right now, much of the community (and the core contributors) is in Discord, which also fills these roles, so we are hosting the QRL Contributors on Discord initially. It should be noted however, that these requirements are system agnostic so it’s possible to change platforms, should the need or desire arise.

In practice

The structure is kept as simple and potent as possible to keep onboarding a relatively light endeavor.

Visitors are able to view discussions, but not add to them. Through viewing the discussions at play, as well as any outstanding tasks that need to be done, a visitor might want to apply to take on a bigger role as a contributor.

Once accepted as a Contributor,** they can self-assign **one or more roles. These roles can be seen as specialisations that a person has. Some examples would be ‘developer’, ‘designer’, ‘writer’, and ‘marketer’. Roles are something that’s taggable, as in practice, another contributor might need some insight or help from members of the team that have a specific specialisation.

Along with roles, also self-assigned are Working Groups (WG)’s, which can be seen as committees that come together to achieve specific ongoing goals. Often a working group is similar to the role or specialisation (ie. ‘wg-marketing’), but not always (ie. ‘wg-documentation’, ‘wg-website’).

For things that are temporary in nature, but are large enough to warrant a committee of their own, there’s also Projects which are elected and can be self-assigned. Some examples of projects might be for videos and the organisation of events.

While the core contributors and a select group of community contributors utilise this system, it’s possible some of the above structure will change before the public release. What is described is how it is now, as of this writing.