Skip to content

Latest commit

 

History

History
220 lines (161 loc) · 14.7 KB

CONTRIBUTING.md

File metadata and controls

220 lines (161 loc) · 14.7 KB

How to contribute

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

These are the general rules for contributing to any Liri repositories, which are hosted in the Liri 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.

First of all we need you to sign the Contributors License Agreement for all non trivial contributions. Please read more here.

Table Of Contents

Code of Conduct

I don't want to read this whole thing, I just have a question!!!

How Can I Contribute?

Style Guides

Additional Notes

Code of Conduct

This project and everyone participating in it is governed by the Liri Code of Conduct.

By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].

I don't want to read this whole thing 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.

How Can I Contribute?

Reporting Bugs

Users are encouraged to take care of following aspects while reporting issues.

1. Be gentle

We are volunteers, most of us work on our spare time primarily because we enjoy it. Please be gentle, it's often difficult to set deadlines in stone for new releases or bug fixes. If you are in hurry and have skills to program, please consider contributing code and documentation.

2. Do not say "it's not working"

Developers are inherently objective and analytical. If the software is not behaving as expected, please explain in details what is actually happening. It is useless to just say it's not working. Eg if you are seeing a blank screen, do not say you are seeing "nothing" it better to say you are seeing a blank screen.

3. Make no implicit assumption

If you are stating something be very sure about it, if you are thinking or assuming something make it clear that you assumed something.

4. Give specific examples even if you are referring to an universal set

If a bug exists for a collection of input factors, try to give specific instances of the input. Eg suppose a thing does not work for any of the users, you should report that "it did not work for any of the users and we tested it for sam and joe".

5. Choose a proper subject

Choosing a proper subject allows us to make a mental map when we glance over a list. We are quickly able to think about dependencies and priorites in a glance.

  • A proper subject should be a one liner preferably less than 80 chars.
  • It should indicate the extent of the problem.
  • It should summarize as comprehensive as possible.

6. Provide a minimal replication procedure

Replicating a bug is a demanding activity.

Mention all the steps that are necessary to repeat the problem.

Also attach a compressed minimal program source code to reproduce the problem, complete with information about your development environment.

7. Provide details and evidence

It helps greatly to attach screenshots and videos of a problem specially when you are referring to visual issues.

8. Keep the developers updated of any new observation regarding the issue

Please report new observations as you find them. Every bit of information helps since it is often difficult to give immediate response.

9. Report-back workarounds

If you find a workaround for a issue please update the report indicating it so that others can use it temporarily. It greatly helps developers also as sometimes the workaround can be precursors of the formal solutions.

10. Report software versions, setup, tool chains, etc...

Report what Qt version you are using, operating system (Android, Windows, Linux) and your environment in general.

Style Guides

Git Commit Messages

Write good commit messages and use the git flow branching model.

C++ and QML

All code follows the following coding style and conventions, please read:

Additional Notes

Issue and Pull Request Labels

This section lists the labels we use to help us track and manage issues and pull requests.

GitHub search makes it easy to use labels for finding groups of issues or pull requests you're interested in. For example, you might be interested in open issues across lirios and all Liri-owned packages which are labeled as bugs, but still need more information or perhaps open pull requests in lirios which haven't been reviewed yet.

To help you find issues and pull requests, each label is listed with search links for finding open items with that label in lirios/lirios only and also across all Liri repositories.

We encourage you to read about other search filters which will help you write more focused queries.

The labels are loosely grouped by their purpose, but it's not required that every issue have a label from every group or that an issue can't have more than one label from the same group.

Please open an issue on lirios/lirios if you have suggestions for new labels, and if you notice some labels are missing on some repositories, then please open an issue on that repository.

Type of Issue and Issue State

Label name lirios/fluid 🔎 lirios‑org 🔎 Description
feature search search Feature requests.
enhancement search search Improvements over existing features.
easy search search Less complex issues which would be good first issues to work on for users who want to contribute to Atom.
bug search search Confirmed bugs or reports that are very likely to be bugs.
question search search Questions more than bug reports or feature requests (e.g. how do I do X).
help wanted search search The Liri core team would appreciate help from the community in resolving these issues.
duplicate search search Issues which are duplicates of other issues, i.e. they have been reported before.
wontfix search search The Liri core team has decided not to fix these issues for now, either because they're working as intended or for some other reason.
invalid search search Issues which aren't valid (e.g. user errors).
needs info search search Likely bugs, but haven't been reliably reproduced.
needs reproduction search search Likely bugs, but haven't been reliably reproduced.
needs design search search UI design is required before starting with the implementation.
hacktoberfest search search Issues for Hacktoberfest.
upstream search search Issue is caused by an upstream bug.
fixed upstream search search Issues was caused by an upstream bug which is fixed now.
doc search search Documentation.
package search search Packaging issue or missing packaging.
idea search search Idea that needs further discussion before the implementation.
task search search Task.