@burke @grace @ibacher @jennifer - perhaps should we bring the browsing person quicker to what matters most: O3 Ref App?
My suggestion for the pinning order:
Others?
openmrs-esm-template-app?
@mikeforde thanks. Could you speak to that? Is that when you first looked around you thought that such dev onboarding resource was not easy enough to find?
Sorry, may have misunderstood your intent and/or meaning. You said “browsing person”, by which I assumed you meant someone on GitHub having a peek at OpenMRS. Given - if they’re on GitHub or looking at GitHub returns in their browser - they are likely to be a coder and the openmrs-esm-template-app is the easiest way to dip into trying some frontend coding then it would make sense to give it some prominence.
I’d probably leave the REST module somewhere there too. Especially in the O3 world, it’s pretty foundational.
Excellent idea @mksd and very much agreed with @mikeforde’s point too. Here’s how it looks now, LMK any desired changes:
I unpinned the qa-framework repo because we no longer have “one” QA repo; the tests are now embedded directly in individual microfrontend apps themselves. @jayasanka is that fair or is there a qa-specific repo you think should be pinned?
Instead I replaced that with esm-patient-chart since we reference that a lot.
I do think it’s very important that we keep in mind that QA covers more than just UI-driven e2e tests. In particular, we also have tests that validate that OpenMRS can be installed against a couple of databases, etc. But, it’s better if we don’t have a single QA repo since the QA work should be distributed along with the code it tests, as much as possible.
Oh 100% agreed to both points @ibacher 
To be more specific, I thought we aren’t using this one anymore, maybe I’m wrong? GitHub - openmrs/openmrs-contrib-qaframework
Yes @grace, we can go ahead and unpin that repository, as it’s currently being used to test functionalities with the old UI.
@mksd sorry what do you mean? Do you mean you’d hope to see different text here:
It doesn’t look like we can change that text without actually changing the repo name.
Great catch. Thanks Ian for the fast turnaround too. Minor updates done to almost all of them. Would it be reasonable to add (“Backend”) to openmrs-core?
Since “reference application” doesn’t mean anything to the layman and beyond, I think we shouldn’t be shy in saying/promising there all that’s not being said in the name. An idea:
Our EMR product running a starter reference configuration.
Don’t always have a license per repo, but everything we release is MPL 2.0 with Healthcare Disclaimer. That said, there’s actually no license file in that folder mostly because the license was a bit up-in-the-air with the Bahmni modules we included.
I’m on-board with that. However, my experience is that people unfamiliar with EMRs don’t usually think about the fact that you need to configure it, so I think the idea of having “a starter reference configuration” is more likely to make people say “wait… is this what I want? I just want OpenMRS!” and I’d rather a short description that makes it clear “This is OpenMRS!”
I think about it like this: openmrs-core is basically the equivalent of openmrs-esm-core; that is, they pull together the core framework which enables the backend or frontend to exist, but I’m not sure I’d describe openmrs-esm-core as “the frontend” and I have similar doubts about describing openmrs-core as “the backend”. Maybe “The core implementation of the OpenMRS data model and backend framework”? That’s technical to parse, but it’s both more accurate and descriptive (I think) than the current text. Put another way, most of the time that frontend devs are interacting with “the backend”, they are talking directly to the FHIR2 module, the REST module, or one of the other modules that provides a REST and / or FHIR interface.
