Who else thinks we’re way overdue for an OpenMRS developer event? We’d like to plan something to happen by mid-2014. This event could take lots of forms:
a hackathon/contest (traditional, where groups work in teams for the best solution to a problem)
bug fest (who can squash the most bugs from the issue tracker?)
review party (let’s review all the outstanding code out there and get it merged)
something else?
Be creative and don’t let cost or other “barriers” prevent you from coming up with great ideas. (We’ll figure out those challenges when the time comes.)
So, please add your ideas here on what you think would be fun and useful for the community. Let’s also hear what you wouldn’t want to do, and why!
Hack on Implementer’s meeting “OpenMRS in a box” ideas
Build Projects that can be done inline with other community work as in after the hackathon multiple groups can go off and work on these projects to report back. Reporting back in 3rd quarter for results and awards
On making our CI work better so we can deploy on demand
There have been several things that we’ve bumped up against for a while that could be advanced with some focused effort:
Knock out some significant issues identified by SonarQube
Pick something off the API 2.0 Wish List (e.g., convert datetime to timestamp)
Take the fine work done on integration testing and bring it into the daily life of our developers – i.e., make it so easy that integration tests are written as often as unit tests
Remember memory! Find the top ten memory leaks or hogs in OpenMRS and fix 'em
Develop-a-thon: what can you do in 1-2 days that will improve OpenMRS development to the point that OpenMRS devs will be using it every days for the next 5-10 years or more because it make developing so much more awesome?
And, of course, have a fun competition making OpenMRS 2.0 Apps
Alternative data source to speed up access (e.g. reporting). MySQL is good for concurrency, but probably not so much for fast access. Dual persistent approach (polyglot)?
Create preparation for upgrade module that will help large implementation to upgrade without bringing the server down for several tens of hours, we already have an idea on how to do this, i believe we can use a hackathon to bring the idea to life, we might not get it done at the hackathon but we can get the ball rolling.
I would suggest to improve technical details in wiki pages about creating apps with OpenMRS 2.0 and etc. I feel like we needs to have more solid structure for setup OpenMRS 2.0 in wiki pages
Creating new intro tickets for new comers. It better to have low complexity ones first. From my experience if someone can hit one ticket and fixed it, new comer would more like to continue it as he is happy at the first movement. We may need some reviews on existing tickets and create new ones.
I have seen that there is a huge list of people who are assign with tickets specially in trunk. I think most of them are not working extensively with those tickets. Free those ticket will helpful for new comers to grab easy ones.
Brainstorming session for improve the capabilities of existing core modules features in OpenMRS. In every GSoC, there are several modules added to the OpenMRS repo. But some of them are not using due to lack of features or low visibility. Having this session and create project ideas from improve existing modules which can use for GSoC programs also will be a very good option. Core modules still may have needed very good features.
Planning for migrating existing modules for use new UI framework
Discuss about how new module can built on top of new UI framework
Since we are not using legacy user interface in future, we would better plan from now how to build new modules on top of new UI framework so we no needs to convert them from legacy user interface to new UI.
