How To Contribute

Easy Tasks

What if you want to contribute but you don't know what? Willing to get involved surely means you are happy about the project, it means you like it and want to help around it.

First, you can try a development release or checkout the code from git master and test it on your system (or any of the feature branches if they exist). This way you'll be able to use the software before the next release and find bugs or regressions that can then be fixed. The more people that test the software the better XFCE's next stable release will be.

Second, you can help with the bugs in Bugzilla. Check out some of the bug reports and try to reproduce them or see if they even apply anymore. Anytime a bug is updated the maintainers will get an e-mail and can follow up. This way old bugs that have been indirectly fixed can be closed out or wrongly filed bugs can get moved to the right component. If you find additional ways to reproduce a bug add it to the bug report. The additional information may help narrow down the exact cause of the bug which means it's much easier and faster to fix. If there are patches attached to the bug report you can test them out and report if it does or doesn't fix that issue. Sometimes a maintainer may be waiting for feedback before applying a patch, especially if they don't have the capability to verify the fix on their setup.

Third, you can help keep XFCE's user/developer documentation up to date. This is for the on-line documentation as well as locations in the code such as the man pages. For the on-line documentation you may want to send an email to the xfce4-dev mailing list in case other people are also working on the documentation. That way you can collaborate with them.

Finally, XFCE can always use more contributers. If you have the time and are willing to learn, we're willing to help get you going and work with you! If there's something you'd like added or a bug you want fixed, offering to help is the quickest way to get more people interested in your issue. You can start by chatting with people on IRC or the mailing lists, that's where a lot of people start, or write reviews and blog entries, or you can take the ropes and maintain something.

Internet Relay Chat

The following is a list of primary channels for XFCE on the Freenode IRC network that you can connect to:

  • #xfce (for community support)
  • #xfce-dev (for development discussion)

To join any of the channels, you can use any IRC client such as XChat.

Please be aware that while there may appear to be lots of people in the channels, they may not be at their computers at the time; some people leave themselves logged in so they can review questions when they get back. Please don't be put off if you don't get a reply straight away.

Mailing lists

Mailing lists are discussion groups that use mass distribution of email to reach all subscribers. Mailing lists are ideal when you have limited connectivity and are not able to use real-time discussion methods. XFCE has two separate mailing lists:

  • xfce (for community support)
  • xfce4-dev (for development discussion)

Please note that the mailing lists are moderated. This means you will have to be subscribed to the list for your messages to be directly forwarded to other subscribers.


Translating Xfce will give it the possibility to be accepted by more people. You don't want software that is in English, do you?

Xfce uses a Transifex platform for the translations. By registering in, you can join the translation team of your language or more and start to translate. You can meet with other people from the team and try to share the work together.

If you are new to translations everything is explained here.

Report Bugs

The first thing to do when you are willing to contribute is to write to the developers, let them know you like their application and what you miss in it, simply give some of your thoughts. You will be surprised by the number of people never doing this! Giving feedback takes a short time and it can always be useful for both the end-users and the developers.

So the first place to let developers know about what you think and miss from their application is on the xfce users mailing list. It's public and every one can read and comment it, but you can also send them private messages, they all put their email addresses in the applications you use. Interesting topics will usually be asked to be put on the bug tracking system which brings us to the second place that is on Bugzilla. You need to create an account in order to create new bugs, and when you do you can select the component and the severity between 'normal' and 'enhancement'.

Getting your system setup for better bug reports:

If you do get an XFCE application to crash, it's best to detail exactly what you were doing that led to the crash. The more info you can provide the more likely it is that we can find and resolve that issue. In addition, we need the backtrace of the crash, however most distributions by default make backtrace output useless, the following sites below provide guidance from the respective distros on how to remedy this situation so you can provide all the info we need to fix your issue.


Debian/Xubuntu/Ubuntu/Linux Mint:







Fix Bugs

Well the obvious contribution is to write code of course! Send us patches, write your own feature and contribute it, etc. There is no big picture here. You can attach patches on Bugzilla.

If you lack an idea for a good feature to write, pick up on Bugzilla, it's full of bugs But not all of them are things to fix, some of them are enhancement propositions, check this report of Xfce core components.

All patches should be against the latest version (known as the git master branch).

Source Code Repository

1. anonymous checkouts
git clone git://

You can get the link of any XFCE project from the repository website. When you click on a project, at the bottom of the pages.

2. keep local copy in sync
git pull

Once you have a clone of a repository keeping it up to date with the latest changes is as simple as calling git pull.

3. tag changed files

Commit to local repository:

git add -u

Pull patch out of local repository to add to issue tracker:

git commit

Create and attach patch on the bugtracker:

git format-patch -1

See also

4. Commit messages should be of this form:
#### begin example commit ###
short explanation of the commit (Bug 1001)

Longer explanation explaining exactly what's changed,
whether any external or private interfaces changed,
what bugs were fixed (with bugtracker reference if applicable)
and so forth. Be concise but not too brief.
### end example commit ###


  1. Always add a brief description of the commit to the first line of the commit and terminate by two newlines (it will work without the second newline, but that is not nice for the interfaces).
  2. First line (the brief description) must only be one sentence. It should optionally reference Bugzilla numbers, if they exist.
  3. The main description (the body) is normal prose and should use normal punctuation and capital letters where appropriate. Please attach patches to bug reports (create new ones if required).

Getting a git account

If you want to get your new Xfce plugin/project hosted, or want to takeover maintainership of one of the projects lacking interest (easy to find, look in Bugzilla for pending patches not applied since a good while..), you need to apply for a git account at our (awesome!) release manager. An Xfce developer should fulfill your request and you should be good to go.

  • Our git workflow/policy is described here.
  • Our release policy is detailed here and finally, the release process is detailed here.

User repositories

Contributors now have the possibility to create user repositories. This allows all developers with git permissions to create their own repository with the following wildcard:


This is useful when you have no permission to commit upstream to xfwm4 directly, but you want a branch to build new features or fix bugs and have others test it out:

1. Clone the source repository
git clone git://
2. Add your user repository
git remote add private ssh://[email protected]/users/your-user-name/xfwm4
3. Create a branch
git checkout -b fix-for-bug-1234
4. Make changes
5. Push the branch to your own user repository
git push private

Repos are listed here and with ssh [email protected] you can see your @C permission.