Community Changelogs-Contribution

Community Changelogs is free to contribute and use. You just need a Trusted Wiki account, use it wisely. To get it, please contact with Wiki administrators.

Contributions or suggestions on the forum are also accepted.

Structure of Community Changelogs

Community Changelogs are divided into categories indicating which layer of the system is changed in that release.

• Kernel: It consists of ntoskrnl.exe and modules, FreeLoader (the bootloader) and UEFI loader.

• Setup: It includes reactos, setup, usetup, welcome, and setuplib stuff (i.e. all ReactOS Setup modules).

• Win32 subsystem: It includes WIN32K, NTUSER, GDI, USER32, NTVDM, CSRSS etc and internal parts of DirectX. If you see them or similar components, then it goes into Win32 subsystem category.

• Drivers: All drivers go here. Device, class or filesystem drivers; no matter.

• Shell: ReactOS Explorer and related shell DLLs (shell32, browseui, stobject...).

• System DLLs: Critical DLLs like hal, ntdll, kernel32, advapi32 and DirectX/WineD3D/OpenGL components.

• User-mode DLLs: Every DLL that is not critical.

• Commands and utilities: System accessories, Control Panel applets, Command Prompt, external commands, utilities, tools, services...

• Tasks: Syncs with external components (Please add the version of software synced), build improvements and other trivial stuff.

• Outside the tree: Mention works here that does not take place in ReactOS Git master branch.

How to contribute

• These entries are not strict rules, you are free. However, we have a style, we're targeting day-to-day users here. Using your common sense is enough.

• Think a release is done and sometime, two weeks to a month has passed. Firstly, have a look into commit stream and analyze what's important. Some build fixes and a spree of new functions? Choose. On the other hand, a bunch of technical terms? I think you don't want to copy all of the commit message entirely. Instead, try to find a way to convert them user-readable.

• We should go progressively as usual. Big additions increase probability of errors.

• Until a few days before release, add WIP and Upcoming templates on top. They will be removed when time comes. When a release is branched, WIP template can be removed.

• Most of the commits include JIRA issues or PR numbers. Have a look at them. You'll better see what is done. Sometimes, devs will include what's fixed. Try to avoid way too technical stuff, and add what's done. Also following JIRA regularly is helpful.

• Adding which program is fixed is a bonus. (Example: win32ss/font: Fixed a bug causes Google Chrome not rendering web pages.)

• Try to avoid using function names, instead collect them into a category that is special enough. (example: iphlpapi: Implemented interface name resolving functions.)

• Build fixes, translations, glitch/pixel fixes etc. are not so important. Instead, we should focus on fixes and developments. However, if there's something happened that big, you can also add it.

• Write everything entry by entry. Everywhere you can, write which component or module changed, like Wine commit stream. (example: shell32: Fixed showing disk capacity.)

• After each entry, add committer name or author of the patch/pull request. If there's a collaborative work, add names accordingly.

• If any commit is backported to previous release in release candidate stage, mention it on the previous release instead of the latest. Don't duplicate entries on both releases. (Example: If any bugfix has been done on 0.4.15-dev and backported to 0.4.14-RC, write the bugfix on 0.4.14 Community Changelog. Ignore post-release backports.)

• Previous Community Changelogs will give you idea about how to contribute. Don't hesitate to ask for help! And if your English is bad, please request help.

Ctasan (talk) 10:43, 23 October 2022 (UTC)