Ways Of Working¶
This document outlines the ways in which the team will work together. Note that this document is intended to be an agreement rather than a contract. In short, it identifies and documents the various implicit agreements into one explicit agreement.
Responsiblities¶
In general, both teams will need to participate in all aspects of the product’s development lifecycle, however, in all instances, a single point of responsibility must be identified in order to delineate the area of responsibility for a single team.
Code Integrity¶
Team SPS
Description Ensure that best practices are adhered to from a structural and lifecycle management perspective.
Product Publishing¶
Team SPS
Description Publish updated versions of Verto into the marketplace. This includes betas as well as releases. Note that the CHANGELOG etc, must be updated as well.
Marketing¶
Team VLabs
Description The Verto Volentix narrative. SPS may publish articles featuring aspects of verto outside of the VLabs team.
Feature Priority¶
Team VLabs
Description This is the act of determining what features need to be added to Verto and in what order. These must line up with the architectural priorities. Input from the community at large is solicited.
Additionally, this is an interim responsibility in that, after v1, the process of feature priority will be managed through the community itself without any centralist control. Ie: https://sfosc.org/principles/
Architectural Priority¶
Team SPS
Description Feature-driven requirements from an architectural definition.
Community Communication¶
Team SPS
Description The outreach and management of the community communication on a day to day basis. Note that this differs from marketing as it is directly with the community
Community Escalation¶
Team Staider
Description If someone has an issue with the conduct on the project or finds a security risk, it will need to be escalated to the governance organization, rather than directly to SPS or VLabs.
Community Communication¶
The following is the prefered method of communicating with community members.
Chat¶
The team will use Discord as its main channel of communication with the broader community. Note that the channel is owned by VLabs, however, SPS has full admin writes as of the time of writing.
As is standard practice, the Discord link is published, according to standards, in the ‘.github/CONTRIBUTING.md’ file.
Volentix Developer Updates¶
VDU (Volentix Developer Update) is a short (2 min) video that talks about what’s happening inside of a project.
SPS will, at a minimum, produce the video once a week starting once the work on the road map begins
The uploading and management of the VDU artifacts will be managed by the Volentix marketing team.
Escalation¶
The following defines the escalation strategy for the team. Note that escalation is considered anything that is urgent or critical. In general all escalations are managed by the first tier, and must go through them in all cases, however, the additional tiers exist in case the other tiers are not responding.
Note that, for all intensive purposes, the first tier will be the only tier required for escalation. It should not be common practice to leverage the other tiers.
Finally, all escalations have a maximum response time of 24hrs. This means that communication has been established not that the problem has been fixed. If an issue has no response in 24hrs then the second tier is contacted.
Finally, you are not bound to any one channel for escalation. For example, the email address is listed below, however, if you have a Discord group and prefer it then feel free to escalate that way.