File: CONTRIBUTING.md

package info (click to toggle)
peony 3.2.3-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, sid
  • size: 7,580 kB
  • sloc: cpp: 47,137; xml: 19; sh: 9; ansic: 7; makefile: 4
file content (42 lines) | stat: -rw-r--r-- 2,500 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# Peony contribution guide
## Introduction
If you are reading this page, you might volunteer to be a contributor of this project. There are some suggestions from me.

##  Your role(s)
What role do you want to play in this project? This point is very important.

- If you just find the problem and report a bug, you should be a user of Peony.

- If you are good at one or more foreign languages, you should be a translator.

- If you are familiar with the framework and developing on it, you should be a developer or programer of Peony.

The different character's contribution is equally important. But the threshold is different.

You need to choose your role(s) based on your own situation.

## Start with an issue
If you are a new commer, I suggest you start by emitting an issue. I can get to know you from the issue you submitted, and there's no "risk" in emitting a issue.

## Translators are in short supply
Peony is an i18n project, and it is shamed that I only studied Chinese and English. If you are familiar with English and proficient in other languages, I hope you can help me with the internationalization of the project.

## Pull request will be treated with caution
I need to think carefully about your PR. If your idea doesn't agree with mine or I find a problem during my code review, I may refuse your request or ask you to modify it.

I hope you can do a lot of verification on your work, because this is the code outside my scope, and when the two are combined, I need to be responsible for it. I don't want to let the contribution become a burden due to negligence.

A pull request can also start with a issue, that might be more well founded and friendly.

## Document and verification
It also makes sense to write new documents and verify existing documents. A good document can reflect your contribution level, and the verification of documents reflects your focus. Even though they may not contribute directly to the project, they are still very important.

## Communication
If you have question about the project, just emit an issue for help. I will try my best to answer your questions.

You also can use e-mail contract with me, here is my e-mail address:

> lanyue@kylinos.cn

## More encouragement, less demeaning
It's not easy to make a good project, especially an open source project. I hope that you can respect these labor achievements. If there's something bad to do, it should not be pointed out in a derogatory way, but like the suggestions given in the article.