NURV

What is Holacracy?

Holacracy originated from experiments empowering self-organizing teams conducted by entrepreneur Brian Robertson at his company Ternary Software. It has since been adopted by firms like Zappos and Medium.

Holacracy:

• Teams are living systems that self-organize work through a double-linked constitutional framework.
• Teams are called circles are empowered with clearly defined yet flexible domains of authority and accountability to govern their work autonomously while streamlining centralized coordination. Regular adaptation occurs through a “tensions” process that allows the sociotechnical system to continually evolve in response to changing realities while avoiding bloat or obsolescence. This has led adopters to claim benefits like distributed leadership, engaged teams, and rapid decision making.

What is Scorched Earth?

Officially, most organisations are unable to shut-down or terminate their computing systems and then restart them at a later date with the expectation that everything will come back up as it once was.

NURV creates a Prioritized Directed Acrylic Graph (PDAG) to structure all software services, while maintaining the autonomy of Holacracy development and communication practices.

What is Fossil?

Fossil is a simple, high-reliability, Distributed Software Configuration management System (DVCS) with these advanced features:

Why Fossil over other DVCS like Git?

Additionally, Fossil has benefit through:

• Rich variety of information pages (examples) promoting situational awareness.
• Ability to automatically mirror GitHub projects.
• Fossil can be used comfortably over dial-up, weak 3G, or airliner Wifi.
• Fossil supports “autosync” mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects.
• Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Automatic self-checks verify that all aspects of the repository are consistent prior to each commit.

What is Bug Tracking?

Bug tracking is the process of logging and monitoring bugs or errors during software testing. It is also referred to as defect tracking or issue tracking. This is an important part of software engineering and while Fossil has a dedicated Ticket or Bug Tracking mechanism, NURV overloads the Ticket concept.

NURV is architected to handle Free & Open Source Software (FOSS) & proprietary software lifecycle management via a Holacracy approach.

To facilitate this, NURV provides an entirely isolated circle for Customer questions, feedback, Bug Reporting backed by Fossil’s

• Forums as a searchable list of Questions
• Tickets to report Bugs
• Chat for public questions

NURV’s default permissions are

• Anyone can read Forums (totally public)
• Anonymous logged in users can post to a Forum, Chat, or report Bugs (as to not prevent feedback or discussions)

What are Job Stories?

The job story is about context, motivation and causality – can we design a solution that works for the situation and causes the expected outcome that the user needs and expects?

The format of a job story is critical, but it’s a pretty simple format to follow:

When ____ SITUATION ____,

I want to ____ MOTIVATION ____

So I can ____ EXPECTED OUTCOME ____.

In the above example, the job story might go something like this:

“When my credit card expires, I want to be able to change my credit card so that I can continue purchasing without any problems.” or “When my credit card expires, I want to be notified so that I can update my information without any disruptions to my service.”

What are DevOps Tasks?

Fossil remembers what you actually did, vs GIT which remembers what you should have done. As such GIT commits need structure such as that provided by Conventional Commits to communicate intent to the consumers of the source code. And in this approach chore, ci, docs, and build are all necessary to convey the correct intent.

NURV splits tickets into Job Stories & Tasks specific to DevOps where these typically fall into:

• Update Dependencies
• Mirror GitHub

What is the difference between DevOps and UX Documentation?

Its a matter of focus:

• DevOps focuses on why and how for Developers, Operations, and those of mankind interested within the organisation.
• UX focuses on what can be done, with tips on implementation for consumers of the application, the how is left for the consumer to implement in their work flow.

DevOps documentation needs to communicate an intricate understanding of knowledge and reasoning to justify Architecture Decision Records (ADR) and defend the choices on comparison against new software libraries or technology that may arise in future. By necessity it:

• must be interwiki capable to cross link dependencies between different Holacracy Circles,
• have access to the original question & discussion validating the technology against customers need (Kanban requirement)
• capture the implementation, variations from original design (Forums, Tickets, Wiki, InterWiki)

UX documentation, such as what you are reading now seeks to communicate with users, it may offer a comparison to similar technologies, needs to introduce concepts educationally, build upon them and assist the user in developing an understanding of what they can do. It flows more as a structured & searchable book, than a massive Wiki for knowledge sharing. This book should be distributable independently, offline, printable, and capable of being uploaded to the World Wide Web (WWW).

NURV uses mdBook to create books.

Why maintain a Timeline?

Events of significance happen, and are lost. Sometimes we forget them, other times members of a team weren’t there or we don’t all notice a world-event that impacts the Holacracy Circle’s work.

Fossil has tags that can be applied to Tech Notes expanding their capability beyond just Architecture Decision Records (ADR) to anything that can be categorised and is cleaner to understand when presented on a timeline.

• Nix ecosystem for: ** Horizontal Tooling *** Std *** [Flake Parts)(https://flake.parts/) Modularity ** Vertical Tooling *** Nixago for Config File Management *** DevShell for Development & Automated Build Shells *** Flakes as Nix v2 *** FlakeHub Flake Versioning, Discovery & Simpler Management *** Nix Systems Output only Supported Systems *** Namaka Snapshot Testing *** Haumea FileSystem Based Module for Nix *** Nix-Filter Source Filtering Lib
• MarkDoc for: ** Product Documentation

Structure

MUS: box rad 10px "museum" fit
arrow right  
COL: box rad 10px "collection" fit
arrow right 
box rad 10px "exhibit" fit
COL_: box rad 10px "_collection" "{sensitive}" fit with .n at (0.5*this.wid right of COL.w, 0.325 below COL.s)
arrow down 0.5 then right from MUS.s to COL_.w
arrow right from COL_.e
box rad 10px "exhibit" fit
CUR__: box rad 10px "__" "{curators}" fit with .n at (0.5*this.wid right of COL.w, 0.885 above COL.s)
arrow up 0.5 then right from MUS.n to CUR__.w

• Museum is an organisation or large scale project ** Fossil RBAC controls access ** Forums, Tickets, Chat, Wiki are visible by all logged in users (sans anonymous)

Flow of Work

Kanban style

1. Forum is the starting place for all discussions, ideas, suggestions
2. (optional) Wiki Page created for comparisons, additional information, a central reference point for long-running forum discussions
3. Tech note created should Forum discussion result in Architecture Decision
4. Job Ticket created should Forum discussion result in customer changes & normal Kanban Process
5. Task Ticket created to implement a Tech note or reconcile impact from Forum

NOTE: Task Tickets can be created independent of above, i.e. Update x to y

FAQ

• Why not Git? Git is designed for Bazaar style development, where dry by/anonymous contributions can be made to codebases by anyone, updated over time and merged in if/when they become suitable. Fossil is designed for Cathedral style development, where a team works towards a common goal, changes can never be modified, and development only moves forward.
• Why not Antora? Antora has a hard dependency on Git MarkDoc additionally allows more consistency between development & product documentation