number,Distribution,Feature Development Process and versioning,Testing Processes,Review Process,Deployment Process,Feature Request Process,Bug Reporting Process,Links/Respources,Note
1,Manjaro  ,using Git as versioning system (GitLab),nothing found,nothing found,"explained in the forum how to create an image using a video
CI on GitLab is apparently not used","new features can be requested in the forum, should be ""specific, unambigious, realistic, and actionable""
the support of packages can be requested, with indicators for inclusion and no inclusion","issue tracker in GitLab but rarely used (only 18 issues), no specific guideline found","https://gitlab.manjaro.org/explore/groups
https://forum.manjaro.org/c/manjaro-development
https://forum.manjaro.org/t/about-the-feature-request-category/554
https://gitlab.manjaro.org/documentation/manjaro-user-guide/issues
https://forum.manjaro.org/t/howto-build-your-own-manjaro-spin/65821",
2,Mint  ,"using Git as versioning system (GitHub)
defines/suggests tools for development
defines coding style",github alpha-testing and launchpad,nothing found,daily builds to obtain the most recent changes as binary via personal package archives (PPA),"feature requests are added by the issue tracker - should be clarified in the title that this represents a feature request. Idea tickets are submitted, clarified, processed, and closed. This neither means that the feature is accpeted nor declined - the implementation will be separate","used issue tracker on GitHub
description, what steps  should be performed to finally submit an issue (observation, expectation, reproducability, responsibility, change), namely reproducing the bug, tracking error messages and setting, as well as searching causes of an issue.
It is recommend to detect the responsible package to identify the maintainer (Mint or other distributor) and provide specific steps for reproducion, error messages, expectations of correct behavior, and codes of conduct","https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/
https://linuxmint-developer-guide.readthedocs.io/en/latest/
https://github.com/linuxmint/alpha-testing
https://launchpad.net/~linuxmint-daily-build-team/+archive/ubuntu/daily-builds",github alpha-testing and launchpad link added
3,elementary,"using Git as versioning system (GitHub)
defines/suggests tools for development
defines coding style",nothing found,nothing found,uses the Meson build systems and gives a short introduction to building the code,"can be added as ""wishlist"" issue but might be not accpeted; propose design by issues - recommend to add mockups and add tags, requires substantial effort to create concise and compelling design recommendations","used issue tracker on GitHub
also have bitesized (smaller issues that serve as requirements) and bountied (financed) issues
requires checking whether the issue is already reported, if already reported one should add a thump-up reaction to the issue to indicate importance
issue report requires: specific summary, no subjectivity/ambigiousness, concise but to the point, issues may require further informations, provide support to prepare issue reports","https://elementary.io/en/get-involved
https://elementary.io/docs/code/reference#code-style
https://elementary.io/docs/code/reference#reporting-bugs
https://elementary.io/docs/code/reference#proposing-design-changes
https://elementary.io/docs/code/getting-started",
4,MX Linux,using Git versioning system (GitHub),nothing found,nothing found,nothing found,nothing found,using Bugzilla - no process documentation found,"https://bugs.mxlinux.org/describecomponents.cgi?product=MX%20Linux
https://mxlinux.org/wiki/
https://mxlinux.org/donate/","Donate page says ""contact dev team"" if you want to help"
5,Ubuntu,"Launchpad code with Bazaar
no specific process documented","possiblity to contribute as tester, test writer, and automatic test developer; using Autopilot for creating automated tests
documentation on how to create a testing environment in a virtual machine",nothing found,nothing found,features can be requested within the issue tracking system,"using Launchpad with Malone as issue tracking tool
information on what is not a bug, namely feature requests, support requests, discussion on features, bugs on no default packages
guideline to check the concerned versions of the bug and whether the issue is already reported
possiblity to serve as bug triager (improving reported bugs)
crash reports are automatically reported by Apport together with whoopsie
tool support to gather information of the bug
tool support to create the bug, for example, matching similar report using the short summary
code of conduct/etiquette","https://wiki.ubuntu.com/QATeam
https://help.ubuntu.com/community/ReportingBugs
https://wiki.ubuntu.com/QATeam/Roles/BugTriager
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
https://help.ubuntu.com/community/CommunityHelpWiki
https://ubuntuforums.org/
https://code.launchpad.net/ubuntu
https://askubuntu.com/questions/28440/where-can-i-send-feature-requests",
6,Debian,"explaining required packages for development
best practices to develop packages, namely, file struture of packages, structure/content of the documentation, changelog, configuration (toolbased with Debconf)
process for becoming a debian developer","minimum testing of packages going to be uploaded:
manual installation test, running a Debian specific package checking tool and a differencing tool, check removal and reinstallation, installation of the package in a different location
","for new debian developers, their sponsor (a senior debian developer) has to review the changed packages","describe process of package building and versioning (setting version numbers), using Makefiles to create packages, process to upload packages using the dupload tool
using multiple mirrors maintained by volunteers to distribute server load during download
new developers cannot upload packages themselves, rather their sponsor has to upload the packages after completing the review",features can be requested within the issue tracking system,"using the reportbug program from Debian or via mail
mail: denote concerned package with ist version using a structured header, check whether the bug was reported before, do not report the same bug to upstream maintainer (double submissions), 
report requires complete errror messages/logs, procedure to reproduction, expected vs. observed behavior, suggested fix, environment (configuration, hardware,etc.)
necessity of contact information, no mass bug submission without a previous argumentation on the mail list - possibility to summarize the bug","https://www.debian.org/Bugs/index.en.html
https://www.debian.org/devel/index.en.html
https://www.debian.org/doc/manuals/maint-guide/start.en.html#needprogs
https://www.debian.org/doc/manuals/developers-reference/index.en.html
https://www.debian.org/devel/join/newmaint.en.html
https://www.debian.org/doc/manuals/maint-guide/build.en.html
https://www.debian.org/Bugs/Reporting.en.html
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#bug-reporting",Added link on how to become a debian developer
7,Solus,"using Git versioning system (GitHub)
using scripts for style checking (at least for Budgie)",nothing found,nothing found,"checking policies before including packages (licensing, no server-software, age)
using build system and further tooling for packaging, description on how to configure it properly
describe the release process for packages, namely Friday-syncs",can request new packages within the developer portal,uses two issue tracking systems (a self-implemented developer portal and for a sub-project Budgie - a desktop environment - on GitHub),"https://getsol.us/articles/contributing/getting-involved/en/
https://dev.getsol.us/
https://github.com/solus-project/budgie-desktop/issues
https://discuss.getsol.us/
https://getsol.us/articles/packaging/package-inclusion-policy/en/
https://getsol.us/articles/packaging/",
8,Fedora,"using Git versioning system (on own web plattform)
explains developer workflow - usually create an pown branch from current master, rebase it and then create a pull request
introduce a set of auxiliary tool for development
describe typical problems in a troubleshooting guideline","possiblity to participate in the quality assurance project
schedule test days for a completed change
development of test cases
consistiuted alpha and beta test
beta test as release validation by running automated tests, manually executed tests",A review process for packages is defined in the wiki.,"nightly builds of packages
description of the process and the tooling to conduct the packaging
describe the process, architecture, and tools to create images","features can be requested via Bugzilla, has a list of forbidden features (e.g., proprietary packages
describes a changes policy discussing how developers should share their upcoming changes to further plan release process
necessity to write a proposal as a wiki page describing several apsects of the change, for example, motivation, owner, current state, testing process, documenteation etc.
after discussion and successful acceptence a Fedora person responsible will set up the bug tracker.
one week before beta testing the Fedora person will check the current state of the chage","using Bugzilla as issue tracker - description of Bug tracking is outdated (this described bug status work flow and a guideline how to process a bug, deciding whether it is a bug, setting severity level etc.","https://fedoraproject.org/wiki/Join
https://fedoraproject.org/wiki/Join#OS_Developer
https://bugzilla.redhat.com/
https://fedoraproject.org/wiki/BugZappers
https://docs.pagure.org/releng/
https://whatcanidoforfedora.org
https://docs.pagure.org/releng/contributing.html
https://docs.pagure.org/releng/layered_image_build_service.html
https://fedoraproject.org/wiki/QA
https://fedoraproject.org/wiki/Bugs_and_feature_requests?rd=BugsAndFeatureRequests
https://docs.fedoraproject.org/en-US/program_management/changes_policy/
https://fedoraproject.org/wiki/QA:Tools",Communication apparently primarily on mailing lists referenced in wiki. Found info about review process.
9,openSUSE,"versioning via the opensuse comander (osc) and GitHub
describe process of how to fix bugs","testing core teams that identify bugs as early as possible and report in the issue tracking system, discusses bugs i regular meetings (plan is not updated recently last entry 2013)",nothing found,"definition of a release cycle and project plan 
rules for packaging, for example, forbidden libraries and content
manual and workflow to create RPMs (Red Head Package Manager) packages","using Bugzilla
feature requests can be created in GitHub by a prefix [Feature]","using Bugzilla
describe several special instructions für bug report","https://en.opensuse.org/openSUSE:Submitting_feature_requests
https://en.opensuse.org/openSUSE:Fixing_bugs
https://github.com/openSUSE/osc
https://en.opensuse.org/openSUSE:Build_Service_Tutorial
https://progress.opensuse.org/projects/opensuse-release-process/issues/gantt
https://en.opensuse.org/openSUSE:Testing",
10,Zorin,nothing found,nothing found,nothing found,Modified packages are distributed as ppa via launchpad,nothing found,nothing found,"https://launchpad.net/~zorinos/+archive/ubuntu/stable
https://bugs.launchpad.net/zorin-os
https://zoringroup.com/forum/viewforum.php?f=3
https://launchpad.net/~zorinos/+archive/ubuntu/testing", +added forum
11,Antergos,,,,,,,,inactive
12,CentOS,EXPLICIT. CentOS does not modify the Upstream packaes from RHEL (Redhat Enterprise Linux). There is also a todo list for those searching for ideas on how to participate.,EXPLICIT. Users are encouraged to test packages upstream of CentOS and to report issues in that place.,"EXPLICIT. Source-Code reviews don't happen in CentOS but upstream. However, users are encouraged to monitor changes e.g. in the CentOS wiki.",EXPLICIT. See https://wiki.centos.org/About/Building_8. All sources are pushed to https://wiki.centos.org/About/Building_8. Build server is https://koji.mbox.centos.org/koji/index. ,nothing found,EXPLICIT. Link to Mantis Bugtracker present on Contribution page. Users are actively encouraged to report bugs. Discussion happens on CentOS Developer's mailing list.,"https://lists.centos.org/mailman/listinfo/centos-devel
https://bugs.centos.org/my_view_page.php
https://github.com/CentOS
https://wiki.centos.org
https://cbs.centos.org/koji/index",CentOS does not attempt to add features which RHEL does not have.
13,Arch,"EXPLICIT. https://git.archlinux.org/ holds all packages actively developed by the archlinux project. Arch contributor roles are defined in https://wiki.archlinux.org/index.php/Roles
possibility to develop Arch user repositories (AUR -https://aur.archlinux.org/) - guideline on how to build packages https://wiki.archlinux.org/index.php/Arch_package_guidelines","testing core teams that identify bugs as early as possible and report in the issue tracking system, discusses bugs i regular meetings (plan is not updated recently last entry 2013) https://wiki.archlinux.org/index.php/Arch_Testing_Team explains how to join the testing team and how the testing process takes place",nothing found,"EXPLICIT. Candidates are first deployed to the *-testing repos and then to the core or extra repos for production deployment (https://wiki.archlinux.org/index.php/Creating_packages)
AUR (user packages) submission guideline explaining how to submit own packages https://wiki.archlinux.org/index.php/AUR_submission_guidelines","For arch projects such as pacman, feature requests can be discussed on mailing lists e.g. https://lists.archlinux.org//listinfo/pacman-dev/
also in issue tracker https://bugs.archlinux.org/ as feature request","EXPLICIT. Bugs are tracked on https://bugs.archlinux.org/. Users are encouraged to follow bug-tracking guidelines https://wiki.archlinux.org/index.php/Bug_reporting_guidelines. In particular: if Arch is not responsible for a bug, the problem will not be solved by reporting the bug to Arch developers.
Particular team for security issues https://wiki.archlinux.org/index.php/Arch_Security_Team","https://bugs.archlinux.org/
https://wiki.archlinux.org/index.php/Bug_reporting_guidelines
https://wiki.archlinux.org/index.php/Roles
git.archlinux.org
https://bbs.archlinux.org/", +added forum
14,ReactOS,"EXPLICIT. Developed in C/C++. Uses github for development https://github.com/reactos/reactos. Patches for bugs related to upstream sources, e.g. wine, should be submitted there. Otherwise contributors are encouraged to create github pull requests. There is a ""Where to Start"" section to give aid in finding concrete tasks. There is guide on how pull requests should be managed.",EXPLICIT. Automated regression tests on testman (https://reactos.org/testman/),nothing found,Guides on how to donwload and build with what tools,nothing found,"Explicit. https://jira.reactos.org/
guidelines on bug reporting guidelines in the wiki","https://github.com/reactos/reactos
https://reactos.org/building-reactos
https://reactos.org/wiki/File_Bugs
https://github.com/reactos/rea
ctos/blob/master/PULL_REQUEST_MANAGEMENT.md
https://reactos.org/testman/",
15,Kali,"IMPLICIT. Kali is developed in gitlab (https://gitlab.com/kalilinux/), but it is not clear whether anybody can contribute, or how to become a contributor. There are pull requests in the gitlab. https://docs.kali.org/contribute advocated hosting repository mirrors as the only way of contributing. This may be due to the fact that kali is developed by a company, so they are likely to have processes which are not made public.
there also exist build scripts (https://gitlab.com/kalilinux/build-scripts)
describe the tooling (https://tools.kali.org/tools-listing)",nothing found,nothing found,nothing found,nothing found,"in GitLab https://gitlab.com/groups/kalilinux/-/issues, on separate issue tracking website
and discussions in the forum https://forums.kali.org/forumdisplay.php?13-Kali-Linux-TroubleShooting
description on how to report bugs https://docs.kali.org/community/submitting-issues-kali-bug-tracker","https://gitlab.com/kalilinux
https://gitlab.com/groups/kalilinux/-/issues",
16,antiX,nothing found,nothing found,nothing found,nothing found,nothing found,Bugzilla,,agree
17,KDE neon,"Several gits (for packages https://packaging.neon.kde.org/)
documentation on how to set up development environment (https://community.kde.org/Get_Involved/development)
static style checker (KRAZY - https://community.kde.org/Guidelines_and_HOWTOs/Code_Checking)
seperate section on debugging processes (https://community.kde.org/Guidelines_and_HOWTOs/Debugging)",mentoned unit tests https://community.kde.org/Get_Involved/development#Test_your_changes and explanation of how to create an unit test (https://community.kde.org/Guidelines_and_HOWTOs/UnitTests),description of how to review patches - a particular section abount code review is left out https://community.kde.org/Infrastructure/Phabricator#How_to_review_someone_else.27s_patch,"Rolling release, continous integration (Jenkins) https://build.kde.org/","Bugzilla
same procedure as for bug reports; distinction between bug and feature is explained here https://community.kde.org/Get_Involved/Issue_Reporting","Bugzilla
description on how to report issues (https://community.kde.org/Get_Involved/Issue_Reporting) and conduct bug triaging (https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging)","https://community.kde.org/Get_Involved/Issue_Reporting
https://community.kde.org/Neon
https://packaging.neon.kde.org/
",
18,TrueOS,GitHub,nothing found,Review by core developers,nothing found,Pull Requests,Pull requests,https://www.trueos.org/contribute/,"“Pull requests can be any contribution → new features and bugs
agree"
19,Lite,"Use GitLab (https://gitlab.com/linuxlite)
set of projects (https://www.linuxliteos.com/development.html#oursoftware)",nothing found,nothing found,nothing found,nothing found,"Bountysource
bugs can reported in the forum (https://www.linuxliteos.com/forums/security-bug-fixes/)","https://www.linuxliteos.com/manual/install.html
https://www.bountysource.com/teams/linuxlite","many topics (e.g., testing, feature requests) are discussed in the forum and are somewhat hidden"
20,Lubuntu,"Own Git system,
developers are in a specific team in launchpad, several personal qualities defined (e.g., knowledge of ubuntu and lubuntu), substantial direct contributions, …
Development by application,
Defined tools","Daily image testing (formal test cases)
Testing milestone images (preparing for release, few ays before release archive is frozen and no daily images are produced, testing of Beta and Final, publishing after all tests have been passed)",Guidelines,"nothing found
core developers -> upload all repos
motu (masters of the universe) developers -> upload to multiverse and universe repos",nothing found,"Use Launchpad (account) and apport (tool), with information on (this is shared with Ubuntu as the base distbution)
- Filed against appropriate package
- Clear title
- Steps to reproduce, expected results, actual results, affected versions, notes
- Tags (i.e., lubuntu)
“MOST IMPORTANTLY: if you're not sure if you should report a bug, report it anyway!”
Reports are then reproduced, marked as confirmed, upstream bug report created and linked, startus of triaged, prioritized","https://phab.lubuntu.me/
https://phab.lubuntu.me/w/bugs/
https://phab.lubuntu.me/w/lubuntu-dev/
https://phab.lubuntu.me/w/packaging/code-review/","In general closely collaborating with the Ubuntu community, so many informaiton from there seem to be applicable here, too.

For not provided parts the webpage state that the information is still work in progress

added deployment info"
21,deepin,Gerrit and GitHub (https://github.com/linuxdeepin),nothing found,nothing found,nothing found,Surveys and suggestions in the forum,feedback list where users can report bugs (https://feedback.deepin.org/feedback/list) - submitting a new feedback with a template - also gives a rough discussion on the rules for feedback (https://bbs.deepin.org/forum.php?mod=viewthread&tid=134758),https://bbs.deepin.org/forum.php?mod=viewthread&tid=168498&extra=page%3D1,"Everything can be contributed through pull requests that are reviewed, but I found no details.
Found forum with chinese discussions… (http://bbs.deepin.org/forum.php?mod=forumdisplay&fid=70)"
22,PCLinuxOS,nothing found,nothing found,nothing found,nothing found,nothing found,nothing found,,"Rather closed community, see paper
""'Developers Corner' section of the forum is where to go .....  I'm unsure if any section has open access but you can PM a moderator to arrange access if necessary."" - from forum
added regarding dev and testing from forum

on the forum there is an index thread about testing, which points to some non-open threads which presumably explain the testing process (http://www.pclinuxos.com/forum/index.php/topic,104577.0.html)"
23,Peppermint,nothing found,special ppa for testing purposes (https://launchpad.net/~peppermintos/+archive/ubuntu/testing),nothing found,nothing found,nothing found,Launchpad (https://launchpad.net/~peppermintos),,
24,Endless,GitHub,"nothing found
""Beta testers get early access to new versions of Endless OS or of new features being developed for it in order to help the developers identify and fix bugs or provide feedback on what it being developed.
This category is for discussion of the new software being tested, requests by the developers for testing of certain features, and to provide a high level of support for the beta testing team.""",nothing found,nothing found,nothing found,"nothing found
""This forum is used to gather and track public bug reports.""","https://community.endlessos.com/c/beta-testing
https://endlessos.com/for-developers/",Apparently everything that is not internal to endless-employees is coordinated in the forum. 
25,FreeBSD,"GitHub (https://github.com/freebsd) and svn (https://svnweb.freebsd.org/)
description of how to receive and maintain the committer status (https://wiki.freebsd.org/BecomingACommitter)
description of the sub-projects of FreeBSD (https://wiki.freebsd.org/)","Daily builds that shall be downloaded and tested by community members
Any ports and fixes can be submitted (ideally to the original developers) via pull requests","Community shall check code, ports, …
Review of pull requests by additional reviewer
“Bugathon” (https://reviews.freebsd.org/)",uses a Jenkins (https://ci.freebsd.org/) and creates artifacts (https://artifact.ci.freebsd.org/),"Submitting to ideas list (wiki site) / mailing list
Creating ports of software and maintaining the ports for FreeBSD (long guidelines)","Mailing list and Bugzilla (https://bugs.freebsd.org/bugzilla/enter_bug.cgi)
gives an introduction on how to write a bug report (https://www.freebsd.org/support/bugreports.html)","https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/index.html
https://wiki.freebsd.org/IdeasPage
https://wiki.freebsd.org/BugBusting",
26,SmartOS,"Gerrit (and GitHub issue tracker, but not pull requests)
Contradicting info: ""All the repositories contained within this build use GitHub pull requests for new changes.""
internal (employee-)jira exposed to public at https://smartos.org/bugview/index.html,
so apparently you can contribute new code and create pull requests","Developers can implement own unit and regression tests
Extensive guide on how to run the test suite scripts","Identify suitable reviewers for own changes, ask in chats if necessary",Detailed guide on how to build from Git,nothing found,"File github issues,
Include platform version and description of problem, make dumps available if possible","https://github.com/joyent/smartos-live
https://smartos.org/bugview/index.html","Some additions, apparently you can participate in development on github to some extent"