2014-06-26 Developers Forum

Owned by Burke Mamlin
Last updated: Jun 26, 2014 by Elliott WilliamsVersion comment
4 min read

How to Join

 Click here to expand...

 

By Browser

By telephone

  • US telephone number: +1 201.479.2627

 

Agenda

  • Quickly review previous meeting minutes (5 min)
  • Reviewing Developer Conventions
  • Review next meeting agenda

Minutes

Attendees
  • Daniel Kayiwa
  • Rafal Korytkowski
  • Win Ribeka
  • Alexis
  • Ryan Yates
  • Ada Yeung
  • Geoff
  • James Power
  • Karl Wurst
  • Roger Friedman
  • Vaclav Krpec
  • Elliott Williams
  • Darius Jazayeri
  • Saptarshi Purkayastha
  • Aniketha
Agenda
  • Review of Developer Conventions
Notes
Our "conventions" are behaviors – documented or not – of the OpenMRS Developer Community that are predictable and/or expected.  We use "conventions" instead of "rules" because we sometimes need to behave differently.  Rules would say that this shouldn't be done; conventions make it explicit when we are straying without saying that it's necessarily wrong.
We have witnessed from successes like Ruby, Grails, and even within areas of OpenMRS that conventions can be a powerful tool for a community.  Tools & scripts are easier to build.  The learning curve is lowered.  Entropy is reduced.  Development can be more efficient.
Documented developer conventions
  • Release Conventions???
  • Documentation Conventions???
  • ...
Questions for Discussion
  • What conventions should be seen by a new developer?  How do they see them?  Did this year's GSoC interns see them?
  • Elliott: I have seen various convention pages. (I think I ended up at them from other Getting Started pages.)
  • Vaclav: Coding conventions (via google)
  • alexis: In my point of view; I looked for OpenMRS convention but its not easy to find them; I searched on OpenMRS wiki
  • Karl Wurst: I was pointed to some of them by the developer's guide (Floss Manuals) but have not seen all of the pages listed in the minutes yet.
  • I'm using ctrl + shift + f for coding conventions and the using git page, I didn't look at other pages for a long time
  • Daniel: I only look back to make sure something is written here before I point someone else to the page
  • Wyclif: (same as Daniel)
  • Saptarshi: I've been and seen it improve over the yrs...; Its so much better now!!
  • Roger: we do not have well-documented where someone should create a github repo and if/when it is appropriate to transfer to the OpenMRS github space
  • Darius: +1
  • Are there existing conventions that need to be changed or retired?
  • Elliott and plypy have established JS conventions for the OpenMRS ID GSOC Project
  • TODO: Elliott to draft a proposed set of Javascript conventions for others to review, and incorporate
  • Are we missing some conventions (e.g., where are there differences on how people do things that cause problems)?
  • Sonar brings a lot of code conventions; we should document the important ones. E.g. we should include a link on the Code Conventions page that takes you to a Sonar page showing the Blocker, Critical, and Major checks that it applies
  • Darius: I don't like our @should conventions anymore.
  • Darius: we should have a short code snippet in the Code Style page showing what nice code looks like (instead of just describing it)
  • Wyclif: document that liquibase changesets should include comment and precondition
  • Are there conventions for developing in OpenMRS 2.0?  Is it clear where to find these?
  • Not very clear where to find these. Searching for "OpenMRS 2.0" on the wiki shows a lot of stale pages
  • Two separate things here:
  • 1. How modules fit together to form OpenMRS 2.x, and how you should add to that
  • 2. Coding conventions in the UI Framework
  • What actions could we (the developer community) take in the near-term to improve our conventions or communication of our conventions?  Can we assign these actions to specific persons?
  • Darius: Get Sonar running again! Check for our conventions live there
Parking Lot:
  • Where module code should go on github (/openmrs or /personal)
  • Whether or not to use the github "Merge Pull Request" button
TODOs:
  • Elliott to draft a proposed set of Javascript conventions for others to review, and incorporate
  • Rafal to write down the steps for the infrastructure team to set up sonar on new ci server (like was previously on ci-stg)
  • Rafal to add a link on our Code Conventions page to some helpview of the rules that Sonar applies
  • Darius to write a short code snippet in the Code Style page showing what nice code looks like
  • Wyclif: confirm we have documented (or else document) that liquibase changesets should include comment and precondition; also specify how/if changeset comments should refer to ticket numbers, how changesets should be broken up into multiple changesets rather than lots of changes in one set.
  • (Someone): Create one or more pages under our Conventions wiki page about UI Framework-related development (e.g. GSP conventions)
  • Darius: 
Next Week: Hackathon Planning

TODOs

Transcripts

  • Audio recording of the call: Listen online or download (available after the meeting)