search

jellyfin / jellyfin-meta

A repository to hold our roadmap, policies, and more.
25 stars 4 forks source link

Moving forward for Standardized Git descriptions commits subject and descriptions when merging PR's with Master. #54

Closed acidmanifesto closed 10 months ago

acidmanifesto commented 10 months ago

At times, looking at the git history can be a bit hard on the eyes as there seems to be no consistency with git commit subject lines and description.

Currently, you need to click on the pr id just to figure out what the commit is about.

Screenshot_20231007_122252_GitHub.jpg

This is only a suggestion with examples. Why not put the pr# in the commit description and then the subjectline be in a formate of add/feat/fix/revert/chore, with area identifer in the title and brief summary less than 50 characters.

Then, for the body message, we list in detail the purpose of the commit, followed by pr# that was merged.

Start identifier: Add: additional implementation of existing features Feat: Adding new features not currently implemented Fix: Fixing an issue or "bug" either reported or not Revert: Reverting either a commit or partial commit Chore: dependency update or white space/code style clean up, updating/simplifying methods/code blocks etc..

Area identifiers to follow: Core: code base itself Doc: documentation Dep: dependiences Misc: Miscellaneous

Summary: Self explainatory, 50 chars or less

An example would be when we merge a pr:

SUBJECT LINE:
Fix (core): black screen issue

BODY DESCRIPTION:
fixed an issue with black screens yadda yadda.
Pr#12345

Something like this, moving on in the future, would make the githistory more readable and easily searchable with various git apps such as tortoisegit and others. Would possibly help in also researching past commits as well when attempting to identify any commit/issues dealing with anything ongoing.

Again, this is only a suggestion with examples. Really, it will be up to the project maintainers and admins to decide on what is appropriate.

Edited: typos

acidmanifesto commented 10 months ago

So the hopes of this is to help clean up and standardize the git history moving forward. However, the idea i suggested may not be exactly how the organization would want it done exactly. I figure we have a discussion before determining any PR being made for contributing documentation.