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

From GhostBSD Wiki
Jump to: navigation, search
(Created page with "{{welcome}} {{Navbar Contributor Page}} {{maintenance}} ==Introduction== On this page we would like to give you some rules, if you intend to contribute as a developer, how t...")
 
(→‎Introduction)
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{welcome}}
 
{{welcome}}
−
{{Navbar Contributor Page}}
+
{{Navbar Development Contributor Page}}
−
{{maintenance}}
+
{{restricted}}
−
 
+
 
==Introduction==
 
==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.
+
On this page we would like to give you some rules for developers, how to contribute code and how things need should be done. The following guidline is derived from a statement of Eric Turgeon at 13.06.20  as founder and leader of this project with remarks from Vic Thacker at 30.05.20  on Telegram.
−
 
+
−
 
+
  
 
==Guidline==
 
==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.
 
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.
+
# The only official supported desktop is [[MATE]]. The other DE's are community releases. That might change in the future, but for now, the main focus is [[MATE]]. Nevertheless the same rules apply to the ports and changes to [https://github.com/ghostbsd/ghostbsd-build 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. With other words: ports have only to care about themselves. All files that ports installed need to be tracked, except config files.  
−
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.
+
# Follow the [https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ The FreeBSD porters Handbook] for test or the guideline to make ports. A useful tool is [https://www.freebsd.org/cgi/man.cgi?query=portlint&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html portlint] to verify the port is done right.
−
 
+
# When it comes to the GhostBSD tools, including [https://github.com/ghostbsd/ghostbsd-build ghostbsd-build], work on sorted tickets. If there is no ticket, no code gets in unless it is new port or port updates.  
−
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.  
+
# Please do not create a ticket with questions. It will close immediately with a reply message to join GHostBSD forums or Telegram for questions.  
−
 
+
# If you have an idea, share it with everyone on Telegram. If the idea is good, a ticket will be done.  
−
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.
+
# If you work on a non-official GhostBSD, like [[XFCE]], let everyone know on Telegram, what you are working on, to make sure no one oversteps on other's works.  
 +
# Don't start something that will affect any GhostBSD tool and / or GhostBSD itself 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 with all people who are working on GhostBSD.  Transparency is important to avoid frustrations. That want to contribute may become a concern to ensure effective teamwork.
 +
# If you work with a team spirit in mind and have proved your self you will get a member of the developer team.
 +
# Each change needs to be tested by the developer, and peer reviewed. It is a standard software development  practice. We are looking at having more discipline in our practice as the number of programmers increase. It will improve and help ensure code quality, better documentation, and communication within the group.
  
−
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.
+
For anyone who is not happy with this can start his/her own project.

Latest revision as of 13:54, 19 June 2020

Welcome to Icon Disti GhostBSD.png Guideline: How to Contribute Code.
Development Contributor Page
Porters Guideline Guideline: How to Contribute Code GhostBSD Builds
Back to Icon Disti GhostBSD.pngContribution
Restricted!
Please do not change this page without permission from the author of this page!

Introduction[edit]

On this page we would like to give you some rules for developers, how to contribute code and how things need should be done. The following guidline is derived from a statement of Eric Turgeon at 13.06.20 as founder and leader of this project with remarks from Vic Thacker at 30.05.20 on Telegram.

Guidline[edit]

In the meantime, for those that GhostBSD Github members.

  1. The only official supported desktop is MATE. The other DE's are community releases. That might change in the future, but for now, the main focus is MATE. Nevertheless the same rules apply to the ports and changes to ghostbsd-build and all the other tools.
  2. For ports, make sure new or update port does not change or override a file from other ports, including config files. With other words: ports have only to care about themselves. All files that ports installed need to be tracked, except config files.
  3. Follow the The FreeBSD porters Handbook for test or the guideline to make ports. A useful tool is portlint to verify the port is done right.
  4. 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 or port updates.
  5. Please do not create a ticket with questions. It will close immediately with a reply message to join GHostBSD forums or Telegram for questions.
  6. If you have an idea, share it with everyone on Telegram. If the idea is good, a ticket will be done.
  7. If you work on a non-official GhostBSD, like XFCE, let everyone know on Telegram, what you are working on, to make sure no one oversteps on other's works.
  8. Don't start something that will affect any GhostBSD tool and / or GhostBSD itself without a sorted ticket. The main reason is unplanned changes can affect other's work and affect the main project.
  9. The main point is, to communicate with all people who are working on GhostBSD. Transparency is important to avoid frustrations. That want to contribute may become a concern to ensure effective teamwork.
  10. If you work with a team spirit in mind and have proved your self you will get a member of the developer team.
  11. Each change needs to be tested by the developer, and peer reviewed. It is a standard software development practice. We are looking at having more discipline in our practice as the number of programmers increase. It will improve and help ensure code quality, better documentation, and communication within the group.


For anyone who is not happy with this can start his/her own project.

Retrieved from "http://wiki.ghostbsd.org/index.php?title=Guideline:_How_to_Contribute_Code&oldid=6568"