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🔗.
This is a summary of progress to basic functionality. We use upstream project names where convenient.
|Backup||🧞 Nextcloud||🧞 Deja Dup|
|Text||👍 Synapse||👍 Riot||👍 Riot||🔧 Chatty|
|XMPP||🔧 Prosody||🔧 Chatty|
|Files||🧞 Nextcloud||🧞 Nextcloud||🧞 Nextcloud||🧞 ?|
|Hub||🔧 Keel||🔧 Hub||🧞 Unsure||🔧 GOA|
|👍 Dovecot||👍 K-9 Mail||🧞 Geary|
|Social||👍 Smilodon||👍 Tusky||👍 Amaroq||🔧 Web|
|Tunnel||👍 Keel||👍 OpenVPN||👍 PIA||🔧 CLI|
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 have onboarding teams, so keep digging till you find one you like. Enjoy the journey and happy hacking!
Django Girls Tutorial🔗. If you try only one tutorial, make it this one. A great introduction to the ideas behind web applications. You don't need prior experience with Python or Django.
...more to come!
Projects are listed at source.puri.sm/liberty🔗. 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.
Submit your ticket while it's still fresh! Take a screenshot! Aim for these requirements, and the product owner will make a best effort attempt to complete the submission. Tickets must meet these requirements before being assigned to a milestone:
Log under the correct project. If you're unsure, use liberty/services🔗 and we'll figure it out.
Ticket descriptions must be actionable. Enhancements should include a clearly motivated user story. Bug reports should include steps to reliably reproduce the problem with any account. (See templates below.)
You may include a suggested technical solution, but you do not have to. If you are suggesting a technical solution, you must include a solution-agnostic user story.
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 to my friend, so that only they can read it.
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."
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 reviewed the ticket, set a target 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.