Contribution Tips

To get started send an email from the email address you want to use to the TomEE developers mailing list (dev-subscribe@tomee.apache.org). After you send the subscribe request, the list manager will send you a confirmation e-mail in reply. 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. A confirmation will put you on the dev@tomee.apache.org 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 dev@tomee.apache.org 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!

Check and follow the workflow for contributing.

After a while when people feel comfortable with you as contributor, they 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 now you feel you really can’t ask about it 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 people singing sound like you when you sing, there are better odds you might get up and sign too. 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, 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!

So 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. Don’t work too long in isolation.

Start small, get it checked in (or patch submitted) and work iteratively.

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.