Commit c5055507 authored by David Seaward's avatar David Seaward
Browse files

Streamline the layout and add more definitons.

Signed-off-by: David Seaward's avatarDavid Seaward <>
parent 06f17770
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
## Our Standards
Examples of behavior that contributes to creating a positive environment
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at <>. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at <>
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
This diff is collapsed.
......@@ -3,8 +3,8 @@
[homepage] | [project] | [subprojects] | [wiki] | [tracker] |
[chat] | [microblog]
A Lektor-based static site for ethical service definitions, standards
and components. Content hosted at <>
A static site for ethical service definitions, standards and
components. Content hosted at <>
## Install from source
......@@ -13,10 +13,12 @@ and components. Content hosted at <>
mkdir liberty_services
git clone .
# note the trailing "."
2. Install Lektor with pipsi. (The Debian package doesn't include the
admin interface, see <>.)
2. Install Lektor with pipsi. (Because the Debian package doesn't
include the admin/editing interface, see
sudo apt install pipsi
......@@ -25,28 +27,22 @@ and components. Content hosted at <>
## Usage
1. Launch Lektor in browser
cd liberty_services
lektor server --browse
1. Run `./launch` to launch the notebook in your default browser
2. Click the "Pencil" button to edit a page.
3. Click the "Save" button to make changes.
4. Once you're happy, commit the changes.
4. Once you're happy, commit and push your changes to ``
for review.
## Build and deploy
If you have lost the launch process, just run `./stop` to kill it.
Assumes you can ssh on to the target.
## Build and deploy
1. Build the site
Assumes you can ssh onto the target.
lektor build
1. Run `./build` to build the notebook
2. Confirm build was successful (no error messages).
lektor clean && lektor build
......@@ -2,7 +2,9 @@ title: What is Liberty?
*Liberty* is the technical project behind [Librem One]( This website is aimed primarily at experienced volunteers looking to contribute.
*Liberty* is the technical project behind [Librem One🔗]( The project is managed by Purism, SPC, and everyone is welcome to contribute.
We follow a user-centered software engineering process led by these user stories...
## Primary user story
......@@ -18,3 +20,12 @@ compromising their digital civil rights.
I am a marginalized person with an opinion. I want to intercept online harassment, so that I can communicate safely with friends and strangers.
## Learn more
To sign up for existing services, see <>
If you've already signed up, you'll find [help on the support page🔗](, [news on the Purism blog🔗]( and [smaller updates when you follow🔗](
Like-minded contributions are welcome. We recommend reading our [definitions and scope of work](definitions), [reviewing our contributions page](contributions) and then [diving in🔗]( Project-specific details are provided in the corresponding README.
_discoverable: yes
_model: page
title: Contributions
If you are a respectful, experienced volunteer interested in actively developing client and server applications that solve our [user stories](../), your contributions are welcome. Please dive in!
Alternatively, anyone can support the project financially with a [Librem One subscription🔗](
## Onboarding
Unfortunately we don't have the resources to onboard volunteers without prior experience. If you're curious about the tools we use, here's a short list of jumping off points. Some of these projects do have onboarding teams, so keep digging till you find one you like. Enjoy the journey!
* [Django Girls Tutorial🔗]( If you try only one tutorial, make it this one. A great introduction to web applications using Python and Django.
* ...more to come!
## Project workflow
Projects are listed at [🔗]( Projects follow the same conventions (detailed below) unless impractical. Naturally we rely on and collaborate with a vast number of other libre projects, and follow their conventions when contributing upstream.
## Logging issues
Submit your ticket now and the product owner will help you achieve these requirements:
* Log under the correct project. If you're unsure, use [liberty/services🔗](
* Descriptions must be actionable. Enhancements should include a clearly motivated user story. Bug reports should include steps to reliably reproduce the problem. (See templates below.)
* Where business logic needs to be expressed, use [Gherkin🔗]( ([alternate reference🔗]( and focus on the happy-day scenario. (Undefined edge cases are expected to fail gracefully.)
## User story template
Keep user stories simple and focus on everyday outcomes. Save technical details for the suggested solution. For example...
**User story:** I am an everyday user. I want to send a private message, so that no-one else can read it.
## Bug report template
**Steps to reproduce:**
* Log into the Acme System
* Enter telephone number
* Click "OK" button
**What should happen?**
* Telephone number is saved.
* Return to login page.
**What happens instead?**
* A message appears, "Please do not click this button again."
## Ticket state
* Unclassified. The ticket must be triaged by the product owner.
* On hold. The ticket is valid but indefinitely deprioritized. Volunteer work is welcome. Some valid tickets will be closed rather than put on hold to make the backlog easier to read.
* Ready. The ticket is well-defined, has a milestone and is assigned. The assignee should aim to complete it by the milestone deadline (along with other tickets in the milestone).
* In progress. The assignee has set a due date and begun work.
* Please review. The ticket is reassigned to the product owner. The work is complete and ready for review. For example, there is a screenshot or code has been deployed to the staging environment. If accepted, the ticket and associated MR is closed. If not, it is put back to "Ready" with an explanation.
* Closed. The work is merged or the fix released or the ticket has been canceled.
## Release workflow
We number releases with semantic versioning. Release candidates are [tagged in GitLab🔗]( before testing. Once tested they are released to an environment branch per [GitLab Flow🔗](
_discoverable: yes
_slug: contributions
......@@ -6,11 +6,29 @@ body:
An *ethical service* is one that explicitly protects users from exploitation in this scenario.
The *Liberty Deckplan* is our concrete configuration plan for a well-defined suite of ethical services.
The [Liberty Deckplan](../drafts/deckplan/) is our concrete configuration plan for a well-defined suite of ethical services.
A *Liberty Deckplan Host* (LDH) is a single domain implementing the deckplan to provide ethical services.
[Librem One]( is the flagship LDH installation.
[Librem One🔗]( is the flagship LDH installation.
## Scope
This is a non-exhaustive non-prioritized list of ideals and limitations on the scope of the project. They may change over time.
**One set of credentials.** The full address and passphrase will be used as credentials everywhere. The user will not have to remember variants and special cases.
**Fair value and sustainability.** An operator is assumed to be running a for-profit business charging a fair price for labor (development, maintenance) and tangible goods (storage, bandwidth). Artificial restrictions like throttling or restricted licensing will not be directly supported.
**Upstream first.** Wherever feasible and welcome we will contribute changes to upstream projects, minimizing the delta between our fork (if any) and upstream.
**Engineering not advocacy.** This is a software engineering project managed within the framework of Purism's [already-defined social purpose🔗]( and available resources. We refer to subject-matter experts for further guidance.
**Single end-user, two trusted devices.** We assume that the end-user has two trusted devices where they are the sole user/owner, like a laptop and a phone, and they frequently switch between devices. In general, the end-user should be able to perform task A on one device, and immediately perform task B on the second device.
**Two accounts is a fair solution.** Using two or more accounts solves some user stories, especially those dealing with operations security. Where a two-account-solution exists, solving the problem with one account will be indefinitely deprioritized.
_slug: definitions
_discoverable: yes
_model: page
title: Drafts
_model: page
title: Deckplan
body: The deckplan [definition](../../definitions) is a work in progress.
_model: page
title: Links
To sign up for existing services, see <>
If you've already signed up, you'll find [help on the support page]( and [news on the Purism blog](
If you want smaller, technical updates, you can follow [](
If you're an experienced volunteer interested in *active development of client and server applications*, see the projects listed in []( For an overview, [read the services notebook](
killall lektor
lektor server --browse
killall lektor
......@@ -11,7 +11,7 @@
%}><a href="{{ '/'|url }}">Welcome</a></li>
{% for href, title in [
['/definitions', 'Definitions'],
['/links', 'Links']
['/contributions', 'Contributions']
] %}
<li{% if this.is_child_of(href) %} class="active"{% endif
%}><a href="{{ href|url }}">{{ title }}</a></li>
......@@ -23,6 +23,6 @@
{% block body %}{% endblock %}
&copy; Copyright 2019 by Purism SPC. Unless otherwise noted, page contents are shared under <a href="">Creative Commons BY-SA 4.0</a> license terms.
Services notebook. Copyright 2019 Purism, SPC. Unless otherwise noted, page contents are shared under <a href="">Creative Commons BY-SA 4.0🔗</a> license terms.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment