OpenCRVS
v1.4
v1.4
  • 👋Welcome!
  • CRVS Systems
    • Understanding CRVS
    • Effective digital CRVS systems
    • OpenCRVS within a government systems architecture
    • OpenCRVS Value Proposition
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • Users
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 6. Issue certificate
      • 7. Search for a record
      • 8. View record
      • 9. Correct record
      • 10. Verify record
      • 11. Archive record
      • 12. Vital statistics export
    • Support functions
      • 13. Login
      • 14. Audit
      • 15. Deduplication
      • 16. Performance management
      • 17. Payment
      • 18. Learning
      • 19. User support
      • 20. User onboarding
    • Admin functions
      • 21. User management
      • 22. Comms management
      • 23. Content management
      • 24. Config management
    • Data functions
      • 25. Legacy data import
      • 26. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • Application settings
      • User / role mapping
      • Declaration forms
      • Certificate templates
    • Business process flows in Farajaland
  • Setup
    • 1. Planning an OpenCRVS Implementation
    • 2. Establish project and team
    • 3. Gather requirements
      • 3.1 Mapping business processes
      • 3.2 Mapping offices and user types
      • 3.3 Define your application settings
      • 3.4 Designing event declaration forms
      • 3.5 Designing a certificate template
    • 4. Installation
      • 4.1 Set-up a local development environment
        • 4.1.1 Install the required dependencies
        • 4.1.2 Install OpenCRVS locally
        • 4.1.3 Starting and stopping OpenCRVS
        • 4.1.4 Log in to OpenCRVS locally
        • 4.1.5 Tooling
          • 4.1.5.1 WSL support
      • 4.2 Set-up your own, local, country configuration
        • 4.2.1 Fork your own country configuration repository
        • 4.2.2 Set up administrative address divisions
          • 4.2.2.1 Prepare source file for administrative structure
          • 4.2.2.2 Prepare source file for statistics
        • 4.2.3 Set up CR offices and Health facilities
          • 4.2.3.1 Prepare source file for CRVS Office facilities
          • 4.2.3.2 Prepare source file for health facilities
        • 4.2.4 Set up employees & roles for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure role titles
        • 4.2.5 Set up application settings
          • 4.2.5.1 Managing language content
            • 4.2.5.1.1 Informant and staff notifications
          • 4.2.5.2 Configuring Metabase Dashboards
        • 4.2.6 Configure certificate templates
        • 4.2.7 Configure declaration forms
          • 4.2.7.1 Configuring an event form
        • 4.2.8 Seeding & clearing your local databases
        • 4.2.9 Countryconfig API endpoints explained
      • 4.3 Set-up a server-hosted environment
        • 4.3.1 Verify servers & create a "provision" user
        • 4.3.2 HTTPS & Networking
        • 4.3.3 Create a Github environment
          • 4.3.3.1 Environment secrets and variables explained
        • 4.3.4 Provision environments
          • 4.3.4.1 Building, pushing & releasing your countryconfig code
        • 4.3.5 Deploy
    • 5. Functional configuration
      • 5.1 Configure application settings
      • 5.2 Configure registration periods and fees
      • 5.3 Managing system users
    • 6. Quality assurance testing
    • 7. Go-live
      • 7.1 Pre-Deployment Checklist
    • 8. Operational Support
    • 9. Monitoring
      • 9.1 Application logs
      • 9.2 Infrastructure health
      • 9.3 Routine monitoring checklist
      • 9.4 Setting up alerts
      • 9.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Releases
      • v1.4.1: Release notes
      • v1.4.0 to v1.4.1 Migration notes
      • v1.4.0 Release notes
      • v1.3.* to v1.4.* Migration notes
      • v1.3.5: Release notes
      • v1.3.4: Release notes
      • v1.3.3: Release notes
      • v1.3.1: Release notes
      • v1.3.* to v1.3.* Migration notes
      • v1.3.0: Release notes
      • v1.2.* to v1.3.* Migration notes
        • v1.2 to v1.3: Form migration
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v1.1.* to v1.2.* Migration notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Interoperability roadmap
    • Product roadmap
Powered by GitBook
On this page
  • Requesting a new feature
  • Contributing code
  • License
  • Github Discussions
  • Reporting bugs
  1. General

Contributing

How to contribute to the Digital Public Good for CRVS

PreviousCommunityNextReleases

Last updated 1 month ago

The value of open-source products as digital public goods is that an active community of contributors will help to maintain and grow the product.

The website has a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. Contributors and people new to open source will find the following guides especially useful:

We need your support to ensure that every individual on the planet is recognised, protected and provided for from birth. In this video we explain our product backlog, how to submit issues and how to contribute code.

Requesting a new feature

If you would like to request a new feature or enhancement based on your country's requirements or for improved user / developer experience read the following steps closely.

  1. Perform detailed business analysis on the use case so that you can open a Github "Issue" with a "Feature" (for functional requirements) or "Tech" (for non-functional requirements) label. Alternatively search for existing issues in our Github Project Backlog to see if we already have an issue for this that you will be requiring.

  2. Get in touch with us at team@opencrvs.org to introduce us to your needs so that we can understand if this truly is a gap in functionality or if there is a work-around that may suffice. We will need to understand your project timeline and dependencies in order to evaluate which release the feature can go into depending on our schedule.

  3. Issues must be written from a user perspective as we operate a human-centric approach to all user experience design.

  4. For non-functional requirements, a descriptive title is required. The issue must include Agile Scrum Acceptance Criteria so that your Quality Assurance engineering team can write Test Cases and so that your developers can write unit tests that cover the business functionality.

  5. Email the Test Cases to us so that we can review them and add them to our regression test pack in Test Cafe for the specific release train and all future releases.

  6. Submit a UX/UI design in Figma using UI components that already exist in the "components" package in opencrvs-core. If a UI component or template does not exist, you should discuss with us what you need and our design team can review your proposal.

  7. Technical architects must work with developers to write developer tasks in the ticket. Each task that contributes to the overall feature should be roughly 2 days of work. We use a points score of 3 points per technical task. This helps us to understand capacity and estimate overall time to develop depending on the size of your team.

  8. Your development team can begin work on the tasks only when ALL of the above steps have been completed. The issue will be added to the release backlog and moved into a "Ready to build" status

  9. We operate Test-Driven-Development methodology. Unit tests for business functionality must be written (for both front & back end logic). We expect at least 80% test coverage on your pull request.

  10. For functional requirements, an end-to-end test must be written. We are currently using Cypress for this. Our development team can guide you how to set up Cypress and show you where tests must be written.

  11. When steps 9-11 are complete, the issue can be moved into a "Code Review" status. Open a pull-request and add the label "Waiting For Review". Maintainers from across our community will review the issue, business requirements and check your code and experience in order to decide if the acceptance criteria have been met. Pay attention to questions and address feedback to satisfy the maintainers.

  12. Once code review has completed your code will be merged and deployed to our QA environment. Your QA team can review the feature and open any associated bugs. Your team must resolve all associated bugs with the feature that you built.

  13. Once the feature is bug free, it will be merged into develop and ready for the release train.

  14. Once all other issues in the release train are ready, the release regression QA will commence. If more bugs are found in this stage or in penetration testing related to your feature, your team must act quickly to resolve them. Once regression is complete, the release will be published.

We sincerely look forward to welcoming you to our maintainer community. If you successfully complete the above steps to contribute new functionality to the global community, and become a maintainer contributing to this global public good, code-reviewing other fetaures that are raised, you will receive wonderful honour!

Contributing code

License

Github Discussions

Reporting bugs

If you are certain this is a new, unreported bug, you can submit a bug issue. Open an issue and add the label "Bug". Use the "Bug" template and complete all the required information. Critical information includes the release number of OpenCRVS.

Include all the steps required to reproduce the bug and describe the expected behaviour that did not occur.

Get in touch with us by email to explain your issue, the country implementation you are working on, include the issue number, and explain the severity of your problem. We need to understand your project timeline and dependencies in order to expedite the priority of a hotfix. Please be as honest as you can in order to be respectful to all other contributors and country's needs.

Open an issue with he and write the issue following User Story methodology.

OpenCRVS uses as its source of truth. All contributors work in Github. Please review the file.

By contributing to the OpenCRVS code, you are conforming to the terms of the .

If you need to talk to us at any time regarding technical issues or feature ideas please refer to .

If you would like to report a problem, search in existing Github Issues and see if someone has already opened an issue regarding the same problem and chat with us on .

Take screenshots or record your screen. is a great tool you can use to record a video and paste a link to it into your bug.

t
feature template
Agile Scrum
GitHub
contributing
license
Github Discussions
Github Discussions
Loom
Open Source Guides
How to Contribute to Open Source
Building Welcoming Communities