What follows is an article, “Contribution Tips”,  from the updated Community page on the TomEE website initially penned by David Blevins and improved by the Community, which explains how to get started contributing to Apache TomEE. We’ve been fortunate enough to have had several people join the project since the “The Best Thing I Ever Did Was Open Source” and “TomEE for the Holidays” posts were published.. I cannot think of a better resource to get folks started than the article re-published below.  Regardless of what project you are working on it is excellent advice.

Subscribe to the developer mailing list

To get started

  1. Send an email from the email address you want to use to the TomEE developers mailing list ([email protected]).
  2. After you send the subscribe request, the list manager will send you a confirmation e-mail in reply.
  3. You must reply to this e-mail to complete the process. If you have not received the confirmation request, check that it has not been marked as spam.
  4. A confirmation will put you on the [email protected] mailing list where you can talk to the rest of the community!

Once your subscription is confirmed (sometimes it takes a few hours), send a message to [email protected] with the Subject line “How can I help?” and write a little bit about yourself like where you live and what you might be interested in working on. You will probably be given some tasks outside your interest area just to get you started, but once you get the hang of it you can move to a specific area if you want.

We’re really looking forward to seeing you on the list and learning more about you. Welcome to the adventure!

What is the process?

Below is a fun, but accurate, process diagram showing how we contribute and the steps taken while doing so.  It might not be easy to grok at first, but keep coming back and it will start to make sense.

public void contributeToOpenSource() {

    boolean stillInterestedAndHavingFun = true;
    int taskSize = 1; // start small!

    contributing:
    while (stillInterestedAndHavingFun) {

        Task task = findSomethingInteresting(taskSize++);

        if (!task.hasJira()) {
            createJira(task);
        } else {
            requestToBeAssignedToJira(task.jiraId());
        }

        while (task.inProgress()) {

            chatOnListALittleGetCleverIdeas(task, new Ideas(task));
            hackALittle(task);

            if (task.tooHard() || task.notFun()) {
                // no big deal, try again with something else
                taskSize--;
                continue contributing;
            }
        }

        File patchFile = createSvnOrGitPatch(task);
        attachToJira(task.jiraId(), patchFile);
        askForReviewOnList(task.jiraId());

        while (!committed(patchFile)) {

            try {
                pokeAtSometingElse();
                helpOnUserList();
                dayDream();
            } catch (MoreThanAWeekException e) {
                // Assume it fell off the radar -- happens.
                // Evidence we need more committers.
                bumpThreadOnList(task);
            }
        }
    }

}

After a while when the community feels comfortable with you as a contributor, they can vote you in as a committer and … big surprise … there’s almost no change in the daily routine. You get access to svn and pretty much everything else stays the same. Instead of submitting patches, now you have to help review them and commit them. Instead of learning how to contribute to an open source project, now you have to learn how to help others get involved. And of course it doesn’t happen all at once, you never stop learning these things and you never stop wishing you had more time.

No one cares how much code you can write or how fast you can write it. We all just contribute what we can when we can and there are no expectations on how much, how often, or where. It’s very much about the journey and there is no real end as long as you’re having fun and learning. Probably finding something to do when you do have time is the hardest part … that never changes.

Don’t assume everything has already been discussed a million times and you’re the only one who doesn’t know and so you shouldn’t bother anyone and should just figure it out on your own. That thinking is your enemy. Don’t do that or you will get nowhere … very slowly. So slowly that you will feel that you really cannot ask about it (whatever “it” is), because surely everyone assumes you know it or have done it by now. That thinking is a terrible trap. Ask questions. Post your thoughts.

Don’t worry about asking “stupid” questions on the list — even simple questions have great value. They often lead to surprisingly good discussions. They also have a profound impact on the people around you, the ones you don’t see.

There are always a handful of people silently reading the list and wishing they could participate but are less brave. Whenever someone like you finally does show up and asks basic questions and shows it’s ok, we usually get another 1 or 2 new faces who suddenly find the courage to speak up. Maybe it’s like Karaoke; if the other people singing sound like you when you sing, there are better odds you might get up take the mic. Seeing people like yourself do the things you want to do is inspiring.

You may suddenly get a creative surge and see many, many things that could be done. One thing you learn about open source is that you never know when life is going to intervene and you have to stop. So it’s always really good to get a little tiny thing working, tested,  checked in, and just grow it iteratively as time permits. It is a practice that is key for people of any skill level. And it goes wonderfully with Open Source as it adds plenty of space for new ideas. Stone Soup starts with the stone, not the soup! No matter how big the idea or task, ask yourself “do I really need all of this to get started?”.   Start with the tiniest possible version. And then cut it down again 🙂

Code is easier to grow than change. And with today’s refactoring tools even change is pretty easy. What’s hard is taking a big piece of code and jamming it into another big piece of code, so don’t work too long in isolation. Start small, get it checked in (or patch submitted) and work iteratively.

Things that always need doing

Here are some ideas to get you started, but never be afraid to ask questions on the TomEE developer’s mailing list. Questions are encouraged and always welcome!

  • Final variables & fields are preferred where possible, but a lot of the code is old. Feel free to add them and hand the code back.
  • If you have any skills with code coverage tools, then you’ll probably find way too much to do!
  • Tests are always welcome.
  • There are over a 1,000 TODO comments in the code. Maybe some should be deleted. Maybe some could be completed. They probably all should have a JIRA id on them.
  • Pick a random class, see if you can figure out what it is doing and Javadoc it.
  • Add @Override where applicable. Intellij has an ‘Inspect Code’ feature. Yikes does it produce a lot of output!
  • No doubt there is some exception handling that can be greatly improved.

Obviously, one could get quite bored doing just the above. But sometimes the above tasks can lead to more fun and exciting things. Anything that gets you in and looking at code and actually touching and changing it usually results in questions, discussions, and ideas… then little passions and late nights and lack of sleep and caffeine abuse.

Things to avoid

While there is lots of stuff you can help with, there are a couple of things you should be careful about.

Huge Patches

Huge patches are hard to digest. Try to avoid them whenever possible. Any step forward is a good one. Small steps allow people to see where you’re headed and give input. That’s true regardless if you are a committer or contributor.

Reformatting

Be careful with reformatting code. Try to never mix logic changes with code reformatting. It makes it nearly impossible for others to see what the actual change was.

If you are a committer and want to reformat something, do the reformat as a separate commit before or after the real change. As long as they are separate and clearly marked it should be easy for people to see what is going on. If you are a contributor and want to reformat something, maybe suggest it on the list, but avoid submitting patches that are just reformatting.

Where do I go from here?

Now that you’ve read this article, subscribe to the TomEE developer list and ask, “How can I help?”  You’ll be astonished at the warm welcome you will receive and the guidance the Community will offer you.

Leave a Reply