khanh.pndc/nextcloud-docs
1
0
Fork 0
mirror of https://github.com/nextcloud/documentation.git synced 2026-01-03 02:09:45 +07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #7879 from nextcloud/fix/no-more-mailing-lists

Browse Source 
There are no mailing lists
This commit is contained in:
Christoph Wurst
2021-12-28 16:32:43 +01:00
committed by GitHub
parent 085c9357a2 cf6abe710c
commit 00a081d202
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
developer_manual/getting_started/codingguidelines.rst
View File

@@ -13,7 +13,7 @@ General
* New features are always developed in a branch and only merged to master once they are fully done.
* Software should work. We only put features into master when they are complete. It's better to not have a feature instead of having one that works poorly.
* It is best to start working based on an issue - create one if there is none. You describe what you want to do, ask feedback on the direction you take it and take it from there.
* When you are finished, use the merge request function on GitHub to create a pull request. The other developers will look at it and give you feedback. You can signify that your PR is ready for review by adding the label "5 - ready for review" to it. You can also post your merge request to the mailing list to let people know. See `the code review page for more information <../prologue/bugtracker/codereviews.html>`_
* When you are finished, use the merge request function on GitHub to create a pull request. The other developers will look at it and give you feedback. You can signify that your PR is ready for review by adding the label "5 - ready for review" to it. See `the code review page for more information <../prologue/bugtracker/codereviews.html>`_
* It is key to keep changes separate and small. The bigger and more hairy a PR grows, the harder it is to get it in. So split things up where you can in smaller changes - if you need a small improvement like a API addition for a big feature addition, get it in first rather than adding it to the big piece of work!
* Decisions are made by consensus. We strive for making the best technical decisions and as nobody can know everything, we collaborate. That means a first negative comment might not be the final word, neither is positive feedback an immediate GO. Nextcloud is built out of modular pieces (apps) and maintainers have a strong influence. In case of disagreement we consult other seasoned contributors.

2
developer_manual/prologue/bugtracker/triaging.rst
View File

@@ -40,7 +40,7 @@ General considerations
* If you are not familiar with the GitHub issue tracker interface (which is used by Nextcloud to handle bug reports), you `may find this guide useful <https://guides.github.com/features/issues/>`_.
* You will initially only be able to comment on issues. The ability to close issues or assign labels will be given liberally to those who have shown to be willing and able to contribute.
* Read `our bug reporting guidelines <https://github.com/nextcloud/server/blob/master/CONTRIBUTING.md#submitting-issues>`_ so you know what a good report should look like and where things belong. The `issue template <https://raw.github.com/nextcloud/server/master/issue_template.md>`_ asks specifically for some information developers need to solve issues.
* It might even be fixed, sometimes! It can also be fruitful to contact the developers. Tell them you're triaging bugs and share what problem you bumped into. Or just ask on the test-pilots mailing list.
* It might even be fixed, sometimes! It can also be fruitful to contact the developers. Tell them you're triaging bugs and share what problem you bumped into.
* To ensure no two people are working on the same issue, we ask you to simply add a comment like "I am triaging this" in the issue you want to work on, and when done, before or after executing the triaging actions, note similarly that you're done.
To be able to tag and close issues, you need to have access to the repository. For the core and sync app repositories this also means having signed the contributor agreement. However, this isn't really needed for triaging as you can comment after you're done triaging and somebody else can execute those actions.