elementary / contributor-docs

description
Everything that we make is 100% open source and developed collaboratively by people from all over the world. Even if you're not a programmer, you can get involved and make a difference.

Contributor Guide

{% hint style="info" %} Looking for documentation on creating your own apps? See Developer Documentation instead. {% endhint %}

Localization

elementary OS is created and used by people from all around the World; help us make the experience even better by translating it into more languages. Both elementary OS and our website are openly translated using an online platform called Weblate

{% content-ref url="broken-reference" %} Broken link {% endcontent-ref %}

Development

Our desktop environment and all its apps are built using Vala, Gtk, Granite, and a number of other open libraries. We host all of our code and do all development openly on GitHub.

{% content-ref url="broken-reference" %} Broken link {% endcontent-ref %}

Feedback

We release updates every month with new features and bug fixes based on the feedback that is reported to us on GitHub. Report Issues, request features, and start discussions directly with the developers and designers that make elementary OS

{% content-ref url="broken-reference" %} Broken link {% endcontent-ref %}

contributor-docs's Issues

Contributing to Icons

Problem

Currently docs are all developer facing, but there's not really anything for designers. We could use some docs for how to get started contributing with design

One specific way for folks to do that is with Icons.

Proposal

We should probably:

• Link to the HIG section on iconograpy: https://docs.elementary.io/hig/reference/iconography
• Talk about tooling, specifically installing Inkscape
• Differentiate between system icons which should almost always be fd.o icon spec names vs app icons which should almost always be shipped with apps

Prior Art (Optional)

https://github.com/elementary/icons/blob/master/CONTRIBUTING.md

Expand bug reporting guide to include basic debugging

The doc section on Reporting Bugs should be extended to also include basic info on debugging (enabling debugging switches, directories for error output etc) so more useful bug reports can be made.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Document how to get useful backtraces

Bug reports would be much better with proper crash logs, it would also probably help the 3rd party developers to have an easy way to get backtraces.

Here is an example of the steps:
elementary/wingpanel#416 (comment)

Old content shown in search results?

What Happened?

When searching for wingpanel it seems to mention content that is not or no longer on the page:

Steps to Reproduce

1. Search for "wingpanel"
2. Click on result

Expected Behavior

You're brought to the clicked content.

OS Version

7.x (Horus)

Software Version

Latest release (I have run all updates)

Log Output

No response

Hardware Info

No response

Mention "The XY Problem" in bug reporting guide

A common type of bug report we get is someone asking how to do Y, when they really want do Y to solve X.

This is a documented phenomenon here: http://xyproblem.info/

It might be worth mentioning this and how to avoid it in our bug reporting docs.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Explain bitesize issues

Problem

It can be intimidating and confusing for folks to know where to start when first contributing to a repo

Proposal

We should explain the bitesize issue tag and maybe also mention the good first issue tag and the contribute page: https://github.com/elementary/gala/contribute

Prior Art (Optional)

No response

Localization

Problem

translator guide is currently still on the website repo

Proposal

Gotta move it here

Prior Art (Optional)

https://github.com/elementary/website/blob/master/docs/translation-guide.md

Explain contributing.md

Problem

Currently we have some project specific quirks in the contributor guide, but this is sometimes duplicate information and better kept in CONTRIBUTING.md files in each project to stay current. GitHub also surfaces contributing information when it's present, so there's some incentive to have it there in the repo

Proposal

We should move the current quirk info into CONTRIBUTING files on the relevant repos and instead add a section to the intro about looking for CONTRIBUTING.md files on the project repo

Prior Art (Optional)

https://github.com/elementary/icons/blob/master/CONTRIBUTING.md

Design Workflow docs reference Launchpad Blueprints

Probably should change this to GitHub Projects?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Make it easier to install dependeices for Elementary System Applications

When contributing to elementary/music I had to go and check how to install each dependency one by one. It would be better to provide a command to install them all, or some other way (e.g. a manifest):

sudo apt-get install libnumberone-1.0-dev libnumbertwo-1.0-dev

Mention "The XY Problem" in bug reporting guide

A common type of bug report we get is someone asking how to do Y, when they really want do Y to solve X.

This is a documented phenomenon here: http://xyproblem.info/

It might be worth mentioning this and how to avoid it in our bug reporting docs.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Link to Project boards

Problem

Finding somewhere to start contributing can be overwhelming for new contributors. It’s not clear what is currently being prioritized and it can be hard to get an idea of overall direction/goals

Proposal

We should highlight our projects page on GitHub. Projects provide better entry points for getting involved in current development priorities.

Prior Art (Optional)

No response