Skip to content

Commit c585d51

Browse files
tareknaservincenzopalazzo
tareknaser
authored and
vincenzopalazzo
committed
refactor: move CONTRIBUTING file to project home
Signed-off-by: Tarek <[email protected]>
1 parent 500775c commit c585d51

File tree

2 files changed

+162
-18
lines changed

2 files changed

+162
-18
lines changed

‎CONTRIBUTING.md

+145
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
# Contributing to Coffee
2+
3+
## Table of Content
4+
5+
- Introduction
6+
- Code Style
7+
- Commit Style
8+
- How to make the release
9+
10+
## Introduction
11+
12+
Welcome to the HACKING guide and let's peek into how a day in the life of
13+
a **Coffee** plugin manager maintainer looks like.
14+
15+
After reading this, you should be prepared to contribute to the repository
16+
and be a potential maintainer in the future if you desire!
17+
18+
Before starting developing you can with `make setup` to configure all
19+
the necessary check before create a commit.
20+
21+
## Code style
22+
23+
To ensure consistency throughout the source code, these rules are to be kept in mind:
24+
25+
- All features or bug fixes **must be tested** by one or more specs (unit-tests).
26+
- All public API methods **must be documented**. (Details TBC).
27+
- Four spaces
28+
- Call `make fmt` before committing
29+
- If you can, GPG-sign at least your top commit when filing a PR
30+
31+
### If You Don’t Know The Right Thing, Do The Simplest Thing
32+
33+
Sometimes the right way is unclear, so it’s best not to spend time on it.
34+
It’s far easier to rewrite simple code than complex code, too.
35+
36+
### Use of `FIXME`
37+
38+
There are two cases in which you should use a `/* FIXME: */`
39+
comment: one is where an optimization seems possible, but it’s unclear if it’s yet worthwhile, and the second one is in the case of an ugly corner case which could be improved (and may be in a following patch).
40+
41+
There are always compromises in code: eventually, it needs to ship. `FIXME` is grep-fodder for yourself and others,
42+
as well as useful warning signs if we later encounter an issue in some part of the code.
43+
44+
### Write For Today: Unused Code Is Buggy Code
45+
46+
Don’t overdesign: complexity is a killer. If you need a fancy data structure, start with a brute force linked list. Once that’s working, perhaps consider your fancy structure, but don’t implement a generic thing. Use `/* FIXME: ...*/` to salve your conscience.
47+
48+
### Keep Your Patches Reviewable
49+
50+
Try to make a single change at a time. It’s tempting to do “drive-by” fixes as you see other things, and a minimal amount is unavoidable,
51+
but you can end up shaving infinite yaks. This is a good time to drop a `/* FIXME: ...*/` comment and move on.
52+
53+
## Commit Style
54+
55+
The commit style is one of the more important concepts when managing a monorepo like **Coffee**, and in particular, the commit style is used to generate the changelog for the next release.
56+
57+
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
58+
format that includes a **type**, a **scope** and a **subject**:
59+
60+
```text
61+
<type>(<scope>): <subject>
62+
<BLANK LINE>
63+
<body>
64+
<BLANK LINE>
65+
<footer>
66+
```
67+
68+
The **header** is mandatory while the **scope** of the header is optional.
69+
70+
All lines in a commit message should be at most 100 characters! This ensures better readability on GitHub as well as in various git tools.
71+
72+
The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
73+
74+
Some couple of examples are:
75+
76+
```
77+
docs(changelog): update changelog to beta.5
78+
```
79+
80+
```
81+
fix(release): need to depend on the latest rxjs and zone.js
82+
83+
The version in our package.json gets copied to the one we publish, and users need the latest of these.
84+
```
85+
86+
### Types
87+
88+
- **feat**: A new feature
89+
- **fix**: A bug fix
90+
- **deprecate**: Deprecate a feature and start to the removing process (3 official release or 1 major release)
91+
- **remove**: End of life for the feature.
92+
93+
### Scopes
94+
95+
- **core**: Changes related to the main functions
96+
- **cmd**: Changes related to the cli package
97+
- **docs**: Changes related to the documentation of the crate
98+
- **github**: Changes related to the github interface
99+
- **lib**: Changes related to the core library package
100+
- **storage**: Changes related to the storage package
101+
102+
### Subject
103+
104+
The subject contains a succinct description of the change:
105+
106+
- use the imperative, present tense: "change" not "changed" nor "changes"
107+
- don't capitalize the first letter
108+
- no dot (.) at the end
109+
110+
### Body
111+
112+
You are free to put all the content you want inside the body, but if you are fixing try to
113+
[follow this indication](https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=signed%20off#describe-your-changes) and do not waste the body space, also it is preferable that if
114+
you fix an exception or some wrong behavior you must put the details or stacktrace inside the body ensure sure that the search engine indexes it.
115+
116+
An example of commit body is the following one
117+
118+
```
119+
checker: fixes overloading operation when the type is optimized
120+
121+
The stacktrace is the following one
122+
123+
} expected `Foo` not `Foo` - both operands must be the same type for operator overloading
124+
11 | }
125+
12 |
126+
13 | fn (_ Foo) == (_ Foo) bool {
127+
| ~~~
128+
14 | return true
129+
15 | }---
130+
description: "`Rust core lightning Rust framework` HACKING guide"
131+
---
132+
```
133+
134+
## How to make the release
135+
136+
TODO
137+
138+
N.B: Part of this document is stolen from [core lightning](https://github.com/ElementsProject/lightning/blob/master/doc/HACKING.md) docs made with from @rustyrussell 's experience.
139+
140+
>Programs must be written for people to read, and only incidentally for machines to execute.
141+
> - Someone
142+
143+
Cheers!
144+
145+
[Vincent](https://github.com/vincenzopalazzo)

‎README.md

+17-18
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,36 @@
11
# Coffee Plugin Manager
22

3-
Welcome to **Coffee**, the plugin manager for Core Lightning.
4-
It takes care of all the configuration and installation of a plugin for your Core Lightning node.
3+
Welcome to **Coffee**, the plugin manager for Core Lightning.
4+
It takes care of all the configuration and installation of a plugin for your Core Lightning node.
55

6-
Using Coffee, anyone can manage plugins for their Core Lightning node.
7-
Coffee handles all the tedious setup and configuration tasks of the underlying
6+
Using Coffee, anyone can manage plugins for their Core Lightning node.
7+
Coffee handles all the tedious setup and configuration tasks of the underlying
88
Core Lightning plugin infrastructure and the hassle of setting up dependencies.
99

10-
Coffee helps you keep your plugins up to date. With its powerful CLI and git support,
11-
you can easily update your plugin to the latest version, ensuring it works seamlessly.
10+
Coffee helps you keep your plugins up to date. With its powerful CLI and git support,
11+
you can easily update your plugin to the latest version, ensuring it works seamlessly.
1212
So, no matter what your plugin needs are, Coffee can help you get up and running in no time.
1313

1414
To learn more visit our [documentation](https://coffee-docs.netlify.app)
1515

1616
## Packages
1717

18-
Coffee offers a range of resources and libraries to simplify integrating lightning plugins into
18+
Coffee offers a range of resources and libraries to simplify integrating lightning plugins into
1919
your business applications :smile:.
2020

21-
22-
| Package | Description | Version |
23-
|----------------|-----------------------------------------------------------------|------------|
24-
| [coffee_core](/coffee_core/) | Package containing the main implementation of Coffee plugin manager | pre_release |
25-
| [coffee_cmd](/coffee_cmd/) | Package providing CLI to the Coffee plugin manager | pre_release |
26-
| [coffee_github](/coffee_github/) | GitHub interface to the Coffee plugin manager | pre_release |
27-
| [coffee_lib](/coffee_lib/) | The core library to the Coffee plugin ecosystem | pre_release |
28-
| [coffee_storage](/coffee_storage/) | The local storage model package for the Coffee plugin manager | pre_release |
29-
| [coffee_httpd](/coffee_httpd/) | HTTP daemon that expose the public API of coffee | under development |
30-
| [coffee_plugin](/coffee_plugin) | Core Lightning plugin that allow to interact with coffee | under development |
21+
| Package | Description | Version |
22+
| ---------------------------------- | ------------------------------------------------------------------- | ----------------- |
23+
| [coffee_core](/coffee_core/) | Package containing the main implementation of Coffee plugin manager | pre_release |
24+
| [coffee_cmd](/coffee_cmd/) | Package providing CLI to the Coffee plugin manager | pre_release |
25+
| [coffee_github](/coffee_github/) | GitHub interface to the Coffee plugin manager | pre_release |
26+
| [coffee_lib](/coffee_lib/) | The core library to the Coffee plugin ecosystem | pre_release |
27+
| [coffee_storage](/coffee_storage/) | The local storage model package for the Coffee plugin manager | pre_release |
28+
| [coffee_httpd](/coffee_httpd/) | HTTP daemon that expose the public API of coffee | under development |
29+
| [coffee_plugin](/coffee_plugin) | Core Lightning plugin that allow to interact with coffee | under development |
3130

3231
## How to contribute
3332

34-
Read our [Hacking guide](docs/docs-book/src/contributing-to-coffee.md)
33+
Read our [Hacking guide](CONTRIBUTING.md)
3534

3635
## License
3736

0 commit comments

Comments
 (0)