This document provides guidance on how to contribute to Eclipse projects. It recommends contributing to projects you are interested in or depend on through documentation, user support, reporting bugs, suggesting improvements, and coding. The best ways to engage and contribute include participating in mailing lists, writing documentation on the wiki, submitting bugs and suggestions through Bugzilla, and providing code reviews through Gerrit. Following specific projects, weighing in on discussions, and submitting code for review are encouraged ways for newcomers to get involved in open source projects.

1. How to contribute to
Eclipse projects?
Mickael Istria - EclipseDay Grenoble 2013
@mickaelistria

2. Which project(s) to contribute to?
●
Any project that:
–
You like and want to get involved in,
–
You use or depend on and want to keep
good/make better,
–
Which makes sense in your strategy

3. What form can a contribution have?
●
Documentation
●
User support
●
Bug reports
●
Suggestion of improvements, based use-cases
≠ “Hey, that sucks!”, “it's retarded”, “WTF?”
●
Code

4. Contribute through the right media:
The taxi analogy
Want to get into a project?
1. Be where it expects you.
2. Make sure they notice you if you want to get into it!

5. Contribute through the right media
IRC

6. Choose the right media
http://www.eclipse.org/forums/
http://wiki.eclipse.org
http://bugs.eclipse.org
https://git.eclipse.org/r
https://dev.eclipse.org/mailman/listinfo/[project]-dev

7. Should I open a bug or not?
In case of doubt, DO IT ! Don't be shy.
- Your idea may be the best idea ever submitted
- Opening a bug doesn't hurt, doesn't cost, isn't bad
- Being wrong doesn't hurt and cost (not knowing you're wrong cost you time/money/happiness)

8. About criticity
Young Lady or Old Hag?
Criticity is not objective. It depends on you, your project, your
stategy... Other contributors may not share your concerns.

9. Don't expect people to do things for
you
(There is no fun image to illustrate slavery.)
You can wish, hope, negociate, buy, lobby,... but not require people to work on your use-case.

10. Obvious good ideas
& good pieces of code
In most cases, your idea will be easily approved, and your contribution
quickly merged into code-base.
Some other contributors might even like your idea so much that they'll
turn it into code without more effort on your side!

11. Discutable ideas
That's the most difficult part: discuss, argue, justify your idea is good.
In such cases, it's good to provide some things to demo.

12. What to do where?
●
Help users on Eclipse forums
●
Write doc on Eclipse wiki
●
Tell developers you write doc on Eclipse
mailing-list
●
Submit bugs via Eclipse Bugzilla
●
Submit suggestions via Eclipse Bugzilla
●
Discuss your ideas on Eclipse Bugzilla
●
Provide code on Eclipse Gerrit
Committers will assist you in integrating stuff into the project.

13. Bugzilla
http://bugs.eclipse.org is the heart of the contribution process,
where most insteresting discussions take place.

14. Follow a project
●
●
●
Follow project-dev@eclipse.org mailing-list
Follow project-inbox@eclipse.org user on
Bugzilla: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email,
under “User Watching”
Follow Gerrit reviews for the project:
https://git.eclipse.org/r/#/settings/projects

15. Weigh in the project
●
●
Give your opinion on mailing-list, Bugzilla
entries and Gerrit reviews (that you're now all
following)
Write code and contribute it via Gerrit.

16. Quick note about Gerrit
●
Empowering reviews:
–
–
Ease discussion about (important) details
–
Ease collaboration
–
●
Ease technical discussions with better tool
Ease knowledge transfer
http://wiki.eclipse.org/Gerrit Gives some hints
and instructions including:
–
Necessary Git Hooks
–
CLA approval
–
Useful Git commands (CLI and EGit)

17. Quick demo: A bug lifecycle with
Bugzilla and Gerrit