Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
dev:howto:contribute [2013/02/02 15:55] – jannisdev:howto:contribute [2020/05/17 21:37] (current) – [Contributing to Xfce] skunnyk
Line 1: Line 1:
 ====== Contributing to Xfce ====== ====== Contributing to Xfce ======
  
 +<note important>This page is outdated. Replaced by https://docs.xfce.org/contribute/start and https://docs.xfce.org/contribute/dev/start</note>
 ===== Purpose of this document ===== ===== Purpose of this document =====
  
-At the time of writing (FOSDEM 2013), the entry barrier for contributing to Xfce is substantially higher than it could be. There are several hurdles that people have to figure out themselves. There is no easily accessible list of low-hanging fruit or tasks to get started with. Also, there is no defined, transparent contribution process. Our aim should be to make obvious to interested developers how they can contribute and what they can contribute.+At the time of writing (FOSDEM 2013), the entry barrier for contributing to Xfce is substantially higher than it could be. There are several hurdles that people have to figure out themselves. There is, for example, no easily accessible list of low-hanging fruit and tasks to get started with. Also, there is no well-defined and transparent contribution process. Our aim should be to make it obvious to interested developers how they can contribute and what they can start with.
  
-The purpose of this document is to come up with a concept for providing low-hanging fruit to the developer community and a contribution process that removes uncertainty about what the right way/format of contributing code is. This document is only about contributing code since other areas, like [[http://xfce.org/getinvolved/translation|translations]], are already well documented.+The purpose of this document is to come up with a concept for providing low-hanging fruit to the developer community and a contribution process that removes uncertainty about what the right way/format of contributing code is. 
 + 
 +This document is only about contributing code since other areas, like [[http://xfce.org/getinvolved/translation|translations]], are already well documented.
  
 ===== Present State ===== ===== Present State =====
Line 30: Line 33:
  
 ==== Contribution Process ==== ==== Contribution Process ====
 +
 +The contribution process aims to provide new contributors with a simple step-by-step process to create and submit changes to Xfce. It is inspired by how the Linux kernel community handles contributions.
  
 === 1. Clone and branch === === 1. Clone and branch ===
Line 46: Line 51:
   * Make sure to pull in the latest Xfce master frequently.   * Make sure to pull in the latest Xfce master frequently.
   * Keep commits clean:   * Keep commits clean:
-    * Make incremental, atomic changes (one aspect at a time) +    * Make incremental, atomic changes (one aspect at a time). 
-    * Keep code working after every commit +    * Keep code working after every commit. 
-    * Comment the code you write +    * Comment the code you write. 
-    * Write commit messages using the standard Git message format +    * Write commit messages using the standard Git message format. 
-    * Don't fear the rebase (against the Xfce master branch)+    * Don't fear the rebase (against the Xfce master branch).
  
 === 3. Push === === 3. Push ===
Line 100: Line 105:
   * Testing the changes.   * Testing the changes.
   * Comments on:   * Comments on:
-    * Coding style and bad code design +    * Coding style and bad code design. 
-    * Potential issues +    * Potential issues. 
-    * Possible side-effects+    * Possible side-effects.
  
 The reviews will be sent as replies to your cover letter and patch emails. Thanks to having the patches included in your submission as plain text, they can be commented on in-line. The reviews will be sent as replies to your cover letter and patch emails. Thanks to having the patches included in your submission as plain text, they can be commented on in-line.