I have looked at the ticket and it looks perfect. So yes, go ahead.
Since your date is still far, you are going to have to create a good number of them because am sure some of the GSOC aspirants are going to steal some of them. They are juicy!
Thank you for mentioning this. I wrote that people need to create an OpenMRS ID under a “mandatory pre-hackathon TODOs” section in the wiki. I am creating a meetup event (with link to the wiki) where people will pre-register, where I will also send out a message to the participants maybe two weeks in advance to remind them to create the OpenMRS ID.
When they have created an OpenMRS ID, do they need to create a helpdesk case to get JIRA access? If so can you please point me to the wiki so I can link that into the hackathon wiki instructions. They need JIRA access so they can claim issues.
haha, yes you are probably right
but I wont be sad, since if they complete the tickets they help us anyway
I think its good to have this much advance since its my first one and this way I also dont put to much stress on the ticket reviewers since they have more time.
@teleivo by the way congratulations on joining ThoughtWorks.
While you were away SDK became the most awesome tool equivalent of the GNU utilities for Linux, I suggest that you help the hackathon attendees set this up as it will speed up your environment setup for the modules especially openmrs-sdk:watch which allows changes to GSPs and Controllers to be autoloaded…
I’ve come up with quite a list of issues (regarding refactoring and adding tests) which I think should be enough for the first time. Unless the GSoC applicants finish them before the hackathon which would be a nice side effect!!!
Am hoping that the people that come enjoy the hackathon and get a long and that we can repeat the event to get some more long term contributions. If you still have ideas for technical tasks that you would like to get done and that have been bugging you for a while, just tell me
Something that bothers me is the high number of warnings Eclipse shows (+1000).
Some of them are slightly hard to fix and test (I’m thinking about the generics ones) but others are easy (variables not used, deprecated methods etc.).
I know it’s not a very interesting task to perform though.
good point! I did go through the most critical sonar issues, and after the critical ones are gone I would tackle the major ones. Unused vars for example where in there so Im sure some issues will be addressed. But I’ll keep that in mind. thanks @lluismf!!
yes, since writing tests for methods that are not tested means you have to understand code that somebody else wrote. so I just wanted to signal to participants that if they are looking for a ticket to start, maybe a simple ‘remove unused …’ is best to do first. but we can also set it to medium. not sure if there is a wiki on this