system/serenity
system/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity synced 2024-07-21 18:15:58 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity

Meta: Add feature policy to contribution guidelines

Browse source
This commit is contained in:
Conrad Pankoff 2020-03-28 20:47:43 +11:00 committed by Andreas Kling
parent 0cbbf6f5eb
commit f1a074a262
1 changed files with 10 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
CONTRIBUTING.md
View file

@ -8,6 +8,16 @@ Everyone is welcome to work on the project, and while we have lots of fun, it's
The easiest way to get in touch is by joining the `#serenityos` channel on the Freenode IRC network.
## Feature policy
As a labor of love, Serenity is strongly user-focused. When proposing or building a new feature, you should start by imagining how a person would use it. Like a tree falling in the woods with nobody around, does a feature with no user impact really provide value?
Maybe your feature involves a GUI application, or maybe it's more suited to a CLI program. Either way, a useful exercise is to imagine what the user interface would be for your idea. Let's say you want to implement a fan speed monitor in the kernel because you recently read about how the related hardware interfaces work - rather than diving right into the kernel implementation, it would be good to imagine how that might be exposed to a user. You might want to build a simple taskbar widget, or maybe a command-line program, or even something as simple as a `/proc` interface, and fill it with mock data to begin with. Whatever your interface is, it should "fit" with the rest of the system, and it should provide some utility to a user.
Sometimes there is no obvious user-facing interface for a feature. In those cases you should still think about the impact that your feature or change will have on a user. If possible, you should devise a way to measure your feature - maybe it reduces memory consumption, maybe it results in fewer page faults, maybe it makes more efficient use of network resources. Whatever that metric is, try to capture it, and provide a summary in your proposal or pull request. If your numbers win, you have a good chance of getting your feature into the system. If your numbers don't win, you have valuable data that you can use to improve your feature.
If you can think of no user-facing interface for your feature, and no user impact at all, please do feel free to start a discussion about it. But please don't spend your precious time building a feature or implementing a change if there's no way for someone to use it and no way to quantify the overall improvement.
## Code submission policy
Nobody is perfect, and sometimes we mess things up. That said, here are some good dos & dont's to try and stick to: