You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
2
+
We love your input! We want to make contributing to Leantime as easy and transparent as possible. There are many ways to contribute:
3
3
4
-
- Reporting a bug
5
-
- Discussing the current state of the code
6
-
- Submitting a fix
7
-
- Proposing new features
8
-
- Translating files
9
-
- Becoming a maintainer
4
+
5
+
## Development Process
6
+
7
+
We use `master` as our primary development branch. All changes should be made through feature branches and pull requests:
8
+
9
+
1. Fork the repository and create your branch from `master`
10
+
2. Create feature branches using the format: `feature/your-feature-name`
11
+
3. For bug fixes use: `fix/bug-description`
12
+
4. For documentation updates use: `docs/what-you-documented`
13
+
5. For translations use Crowdin instead of direct pull requests
10
14
11
15
## We Develop with GitHub
12
-
We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
16
+
We use GitHub to host code, track issues and feature requests, and accept pull requests. Pull requests are the best way to propose changes.
17
+
18
+
### Pull Request Process
13
19
14
-
## We Use [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow), So All Code Changes Happen Through Pull Requests
15
-
Pull requests are the best way to propose changes to the codebase (we use [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow)). We actively welcome your pull requests:
20
+
1. Ensure your code follows our coding standards (PSR-12)
21
+
2. Add/update tests for any new features
22
+
3. Update documentation as needed
23
+
4. Ensure all tests pass locally
24
+
5. Run code style checks:
25
+
```bash
26
+
make codesniffer
27
+
make phpstan
28
+
```
29
+
6. Include screenshots for user interface changes
30
+
7. Update the CHANGELOG.md if needed
31
+
8. Sign the Contributor License Agreement when prompted
32
+
33
+
### Quality Requirements
16
34
17
-
1. Fork the repo and create your branch from `master`.
18
-
2. If you've added code that should be tested, add tests.
19
-
3. If you've changed APIs, update the documentation.
20
-
4. Ensure the test suite passes.
21
-
5. Make sure your code lints.
22
-
6. Issue that pull request!
23
35
24
36
## Contributor License Agreements
25
37
Developers who wish to contribute code to be considered for inclusion in Leantime must first complete a Contributor License Agreement (CLA).
26
38
We use CLA assistant to manage signatures. You will be asked to sign the CLA with your first pull request. Subsequent pull requests will not require additional signatures. Please keep in mind that:
27
-
- If you are an individual writing the code on your own time and you're SURE you are the sole owner of any intellectual property you contribute, you can sign the license as an individual contributor
28
-
- If you are writing the code as part of your job, or if there is any possibility that your employers might think they own any intellectual property you create, then you should reach out to us at [email protected] for a Corporate Contributor License Agreement (this will allow any employee at your company to contribute without having to sign individual CLAs).
29
39
30
-
## Report bugs using GitHub's [issues]([https://github.com/Leantime/leantime/issues](https://github.com/Leantime/leantime/issues))
40
+
## Report bugs using GitHub's [issues](https://github.com/Leantime/leantime/issues)
31
41
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](https://github.com/Leantime/leantime/issues); it's that easy!
32
42
33
43
## Translations
34
44
We use Crowdin to manage our translations. Please update translations in [this project](https://crowdin.com/project/leantime)
35
-
At this point we will stop accepting PRs into the language files directly as this is causing issues with the Crowdin sync process.
45
+
At this point we will stop accepting pull requests into the language files directly as this is causing issues with the Crowdin sync process.
36
46
37
47
## Write bug reports with detail, background, and sample code
38
48
[This is an example](http://stackoverflow.com/q/12488905/180626) of a bug report, and we have modeled the issue templates after that. Here's [another example from Craig Hockenberry](http://www.openradar.me/11905408), an app developer whom I greatly respect.
39
49
40
50
**Great Bug Reports** tend to have:
41
51
42
-
- A quick summary and/or background
43
-
- Steps to reproduce
44
52
- Be specific!
45
53
- Give sample code if you can. [My stackoverflow question](http://stackoverflow.com/q/12488905/180626) includes sample code that *anyone* with a base R setup can run to reproduce what I was seeing
46
-
- What you expected would happen
47
-
- What actually happens
48
-
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
49
54
50
55
People *love* thorough bug reports. I'm not even kidding.
51
56
57
+
## Development Setup
58
+
59
+
1. Fork and clone the repository
60
+
2. Install dependencies:
61
+
```bash
62
+
make install-deps-dev
63
+
```
64
+
3. Set up your environment:
65
+
- Copy `.env.example` to `.env`
66
+
- Configure your database
67
+
- Set up local development server
68
+
69
+
4. Run development build:
70
+
```bash
71
+
make build-dev
72
+
```
73
+
74
+
5. Run tests:
75
+
```bash
76
+
make unit-test
77
+
make acceptance-test
78
+
```
79
+
52
80
## Use a Consistent Coding Style
53
81
We are using the [PSR-12 coding style](https://www.php-fig.org/psr/psr-12/) for PHP.
54
82
@@ -57,10 +85,10 @@ We are using the [PSR-12 coding style](https://www.php-fig.org/psr/psr-12/) for
57
85
As mentioned above we are following PSR-12 naming conventions. Some areas are not covered in the standard and will be covered in this section. For sake of completion we include all naming conventions in this section.
58
86
59
87
**Classes**
60
-
Pascal Case (Example: `leantime.core.controller.frontcontroller`
88
+
Pascal Case (Example: `Leantime\\Core\\Http\\Request`)
61
89
62
90
**Class Methods**
63
-
Camel Case (Example: `$object->getItem()`
91
+
Camel Case (Example: `$object->getItem()`)
64
92
65
93
**Variable Names**
66
94
Camel Case (Example: `$variableName`)
@@ -72,18 +100,16 @@ Camel Case (Example: `$array['indexDefinition']`)
72
100
Macro Case (Example: `MY_CONSTANT`)
73
101
74
102
**Event Strings**
75
-
Pascal Case with periods for the path (Example: `Leantime.Core.Method.SomeEvent`)
103
+
Camel Case with periods for the path (Example: `leantime.core.controller.frontController.someEvent`)
76
104
77
105
**HTML elements, classes, ids**
78
-
Kebab Case (Example: `<div class="my-class" id="my-id">`
106
+
Kebab Case (Example: `<div class="my-class" id="my-id">`)
79
107
80
108
**Blade Components**
81
-
Kebab Case (Example: `<x-global::my-directive>`
109
+
Kebab Case (Example: `<x-global::my-directive>`)
82
110
83
111
**Blade File Names**
84
-
Kebab Case + `blade.php` (Example: my-directive.blade.php`)
85
-
86
-
112
+
Kebab Case + `blade.php` (Example: `my-directive.blade.php`)
87
113
88
114
## References
89
115
This document was adapted from the open-source contribution guidelines for [Facebook's Draft](https://github.com/facebookarchive/draft-js/blob/5dd99d327066f5f0b30b95ab95770822cff1ac65/CONTRIBUTING.md)
"description": "Open source project management system for non-project managers. Simple like Trello, powerful like Jira. Built with neurodiversity in mind.",
0 commit comments