Skip to content

Latest commit

 

History

History
277 lines (182 loc) · 17.4 KB

CONTRIBUTING.md

File metadata and controls

277 lines (182 loc) · 17.4 KB
Raw

Contributing to shared_themes

First off, thanks for taking the time to contribute!

The following is a set of guidelines for contributing to shared_themes, which is hosted in the Savannah Global Health Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table Of Contents

Code of Conduct

TL/DR: I just have a question!

What should I know before I get started?

How Can I Contribute?

Styleguides

Additional Notes

Code of Conduct

This project and everyone participating in it is governed by the SIL Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior via email to BeWell Feedback.

TL-DR I just have a question

Note: Please don't file an issue to ask a question. You'll get faster results by using the resources below.

We have an official message board Support center through which we can interact with community members incase you have questions.

What should I know before I get started?

SIL Software and Packages

shared_themes is an open source project — it's one among many other shared libraries that make up the wider ecosystem of software made and open sourced by Savannah Informatics Limited. When you initially consider contributing to shared_themes, you might be unsure about which of those repositories implements the functionality you want to change or report a bug for. This section should help you with that.

Here's a list of some of the projects:

  • app_wrapper - A shared library for BeWell-Consumer and BeWell-Professional Responsible for putting together everything that the app needs in order to run safely. Similar to a pre-flight checklist that brings together app requirements and exposes them to app's element tree.
  • domain_objects - A shared library for BeWell-Consumer and BeWell-Professional Responsible for aggregating core domain objects.
  • dart_fcm - A shared library for BeWell-Consumer and BeWell-Professional that is responsible for exposing firebase messaging services.
  • user_feed - A shared library for BeWell-Consumer and BeWell-Professional that is responsible for rendering and refreshing user-feed and engagement data.
  • flutter_graphql_client - A shared library for BeWell-Consumer and BeWell-Professional that is responsible for exposing graphql_client and helper methods for use in the various apps
  • debug_logger - A shared library that is responsible for displaying various logging options used for development and debugging
  • misc_utilities -A shared library for BeWell-Consumer and BeWell-Professional that is a wrapper for various shared helper methods and functions
  • shared_themes -A shared library for BeWell-Consumer and BeWell-Professional that is responsible for defining and providing theme/style guidelines
  • shared_ui_components - A shared library for BeWell-Consumer and BeWell-Professional that is responsible for rendering and exposing dumb widgets and ui components
  • user_profile - sil_user_profileis a shared library between [BeWell-Consumer] and [BeWell-Professional] and is responsible for the user profile displayed on both apps.

Design Decisions

When we make a significant decision in how we maintain the project and what we can or cannot support, we will document it in a shared wiki SIL WIKI. If you have a question around how we do things, check to see if it is documented there. If it is not documented there, please open a new issue on the project repo or reach out to us via the official channels and ask your question.

How Can I Contribute?

Reporting Bugs

This section guides you through submitting a bug report for shared_themes. Following these guidelines helps maintainers and the community understand your report 📝, reproduce the behavior 💻, and find related reports 🔎.

Before creating bug reports, please check the project's list of open issues/bug reports as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible. Fill out the required template and the information it asks for helps us resolve issues faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

Before Submitting A Bug Report

How Do I Submit A (Good) Bug Report?

Bugs are tracked as GitHub issues. After you've determined which repository your bug is related to, create an issue on that repository and provide the following information by filling in the template.

Explain the problem and include additional details to help maintainers reproduce the problem:

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps which reproduce the problem in as many details as possible. For example, start by explaining how you started the project, e.g. which command exactly you used in the terminal, or how you used the project otherwise. When listing steps, don't just say what you did, but explain how you did it.
  • Provide specific examples to demonstrate the steps. Include links to files, screenshots or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
  • Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
  • Explain which behavior you expected to see instead and why.
  • Include screenshots and screen-recordings which show you following the described steps and clearly demonstrate the problem.
  • If you're reporting that the project crashed/doesn't build, include a summary crash report with a stack trace if available. Include the crash report in the issue in a code block, a file attachment, or put it in a gist and provide link to that gist.
  • If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened and share more information using the guidelines below.

Provide more context by answering these questions:

  • Can you reproduce the problem?
  • Did the problem start happening recently (e.g. after updating to a new version of the project in question) or was this always a problem?
  • If the problem started happening recently, can you reproduce the problem in an older version of the project? What's the most recent version in which the problem doesn't happen? You can download older versions of this project in its release page on pub.
  • Can you reliably reproduce the issue? If not, provide details about how often the problem happens and under which conditions it normally happens.
  • If the problem is related to working with files, does the problem happen for all files and projects or only some? Does the problem happen only when working with local or remote files. Is there anything else special about the files you are using?

Include details about your configuration and environment:

  • Which version of the project are you using? You can get the exact version by running flutter doctor -v in your terminal.
  • Which version of the flutter & dart SDK are you using?
  • What's the name and version of the OS you're using?

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion for this project, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion 📝 and find related suggestions 🔎.

Before creating enhancement suggestions, please check the list of already proposed enhancements as you might find out that you don't need to create one. When you are creating an enhancement suggestion, please include as many details as possible. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

Before Submitting An Enhancement Suggestion

  • Check the project changelog for tips — you might discover that the enhancement is already in the works and(or) is available in this or a previous version. Most importantly, check if you're using the latest version of this project.
  • Perform a cursory search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.

How Do I Submit A (Good) Enhancement Suggestion?

Enhancement suggestions are tracked as GitHub issues. Create an issue on that repository and provide the following information:

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Provide specific examples to demonstrate the steps. Include copy/pasteable snippets which you use in those examples, as Markdown code blocks.
  • Describe the current behavior and explain which behavior you expected to see instead and why.
  • Include screenshots which help you demonstrate the steps or point out the part of the project which the suggestion is related to.
  • Explain why this enhancement would be useful to most of our users and isn't something that can or should be implemented as a community package.
  • List some other packages or applications where this enhancement exists.
  • Specify which version of the project you're using. You can get the exact version by running flutter doctor -v in your terminal.
  • Specify the name and version of the OS you're using.
  • Specify the name and version of the dart & flutter SDK you're using.

Your First Code Contribution

Unsure where to begin contributing to SIL Software? You can start by looking through these beginner and help-wanted issues:

Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have.

Local development

shared_themes and all packages can be developed locally. For instructions on how to do this, (develop, test & deploy) see the project's readme file

Pull Requests

The process described here has several goals:

  • Maintain SIL Software's quality
  • Fix problems that are important to users
  • Engage the community in working toward the providing best possible software
  • Enable a sustainable system for SIL's maintainers to review contributions

Please follow these steps to have your contribution considered by the maintainers:

  1. Follow all instructions in the template
  2. Follow the styleguides

While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.

Styleguides

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • Our convention for a good commit message consists of a header, a body and a footer.

Message header

The message header is a single line that contains short and clear description of the change.

The following are message header examples that describe the kind of change that a commit is providing.

  • feat (feature)
  • fix (bug fix)
  • docs (documentation)
  • style (formatting, missing semi colons, …)
  • refactor (changing implementation details without changing functionality)
  • test (when adding tests)
  • chore (maintain)

Header subject

This is a very short description of the change.

  • use imperative, present tense: “change” not “changed” nor “changes”
  • don't capitalize first letter
  • no dot (.) at the end

Example of a good commit header

docs: healthcloud commit message convention

Message body

Separated with the Message Header by a line break, the message body contains checklist and summary paragraphs of changes. Follow below conventions.

  • use imperative, present tense: “change” not “changed” nor “changes”
  • includes motivation for the change and contrasts with previous behavior
  • don't capitalize first letter
  • no dot (.) at the end
  • use checklists if more than a single work-item have been tackled

Message footer

The footer should contain any information about Breaking Changes which should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then the description of the change, justification and migration notes. It is also the place to reference GitHub issues that this commit Closes.

Example of a good commit footer

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.

Closes #392

Example of a good commit message

docs: add healthcloud convention to readme

Couple of typos fixed:
- indentation
- syntax highlighting
- start periodic checking
- missing brace

Closes #03

NOTE

  1. The commit message header can be used in solitary with a clear subject on issues with elementary changes.
  2. To close an issue automatically include the footer with a reference to the GitLab issue as demonstrated above.

Packages import

Packages imported in every dart file follow this order;

1 . Dart imports
2 . Flutter imports
3 . Third-party packages
4 . Our own packages
5 . Relative files

All the imports MUST be separated by a blank line. See example below. A good example, using the lib/features/login/pages/login_page.dart file

// flutter package imports
import 'package:flutter/material.dart';
import 'package:flutter_redux/flutter_redux.dart';

// third party imports
import 'package:redux/redux.dart';

// Be.Well Pro imports
import 'package:healthcloud/presentation/login/redux/models/login_viewmodel.dart';
import 'package:healthcloud/presentation/login/widgets/login_page_content.dart';
import 'package:healthcloud/redux/models/app_state.dart';

Additional Notes

For any additional notes/suggestions indicate them through the right channels.