Difference between revisions of "Guideline: How to Contribute Code"

Revision as of 10:26, 16 June 2020

Welcome to Guideline: How to Contribute Code.

Contribution
Development Contributor Page	Code of Conduct	Wiki Contributor Page
Back to Wiki Main Page

Introduction

On this page we would like to give you some rules, if you intend to contribute as a developer, how to contribute code and how things need should be done.

Guidline

Eric Turgeon, [13.06.20 16:39] Hi, has the leader of the project, I recognize the frustrations, no official written guide on how to contribute code and how things need should be done. We did discuss multiple times of the possibility of enforcing PR only. The main reason is that all master needs to be release-ready at any time. Just a significant change I did myself broked the release of May. That manly why I skipped the May release. It was only two lines in ghostbsd-build to fix, but my time was directed more on the unwritten politics of the project.

I think there is a need for workflow/guideline, so I will stop my development work to get a written guide to GhostBSD ghostbsd inside and outside contribution to code to tools and ports. It will mainly be base on the many conversations we had in the past and on the FreeBSD guideline I learn since I have my FreeBSD commit bit. I think it will help newcomers and give us more time to focus on planing and code instead of politics that we don't have time for anyway. I not sure when I will complete it. But I will come back for feedback.

Eric Turgeon, [13.06.20 17:58] In the meantime, for those that GhostBSD Github members.

To clarify, when I refer to GhostBSD, I only refer to Official GhostBSD, which is the MATE. The other DE's are community releases and not an official thing. That might change in the future, but for now, the main focus is MATE. For that reason, with the other DE, I am less strict about them because I do not consider those as official GhostBSD. All that said, the same rule applies to there ports and changes to ghostbsd-build and all the other tools.

For ports, make sure new or update port does not change or override a file from other ports, including config files. All files that ports installed need to be tracked except config files. Follow the FreeBSD ports Handbook for test for the guideline to make ports. A useful tool is portlint to verify the port is done right.

When it comes to the GhostBSD tools, including ghostbsd-build, work on sorted tickets. If there is no ticket, no code gets in unless it is new port ports or port updates. Please do not create a ticket with questions. It will close immediately with a reply message to join GHostBSD forums or Telegram for questions.

Have an idea, share it with everyone here, and if the idea is good, a ticket will be done. If you work on a no official GhostBSD like XFCE, let everyone know here what you are working on to make sure no one oversteps on other's works. Don't start something that will affect any GhostBSD tools and or itself GhostBSD without a sorted ticket. The main reason is unplanned changes can affect other's work and affect the main project. The main point is to communicate what people are working for transparency to avoid frustrations.

Eric Turgeon, [13.06.20 17:59] I am serious about this. I have been asked a couple of times to put my feet down in the ten last years of GhostBSD, I never really did. This project is not what it was 10, 5 or 2 years ago, and a lot changed since last year. We cannot execute this project in the free for all like it was in the past. I am the founder of the project and the leader, I try to not act like a dictator, but now it is time for reformation. I want structure, communication, and transparency.

This is my main statement, for now, Utile I come up with the official written guideline. Now for anyone that is not happy with this, you can start your own project. I started myself to work on that structure for the last few weeks, and I expect the GhostBSD GitHub member to do the same.