We are discussing the composition of the Advisory Board as part of the OpenMRS governance. This is the link to the preliminary thinking about this–there is still lots to discuss, but we wanted you to be aware of this dialogue. This will be added to the Leadership Call Agenda for 28/1/2016.
Please feel free to review and comment on our ideas! thanks for your active participation in the community! terry
Just a reminder to everyone to please provide your feedback on these ideas. We’re very excited to convene this advisory group, but want to hear your feedback before it gets started. Thanks in advance!
We have updated the proposed Advisory Committee guidance. Please comment on this and suggest possible names for consideration for the Advisory Committee. We are hoping to establish the committee within the next 6-8 weeks, so potential names would be helpful by Feb 12. Thanks for your help. Terry
we are still looking for comments and/ or suggestions to our proposed advisory committee construct as well as members! feel free to suggest !! thanks. @terry
It generally sounds good. My one comment is to explicitly say that one type of committee member could be advising on the “broader ecosystem [of Global Health IT]”.
Hi everyone. We’ve prepared this draft “charter” of the advisory council. Please review and reply with your feedback, or bring questions on Thursday for discussion. Thanks!
Advisory Council Charter
Mission
The OpenMRS Advisory Council’s mission is to provide feedback to the OpenMRS Leadership Team, with the goal of helping the community successfully develop and implement its organizational strategy and goals.
Advisory Council Goals:
Provide recommendations, feedback, guidance, advice, and critique for the creation and execution of the annual operational plan,
Provide external networking contacts that could support the OpenMRS community,
Provide specific expertise that addresses the following areas: open source, resource-constrained implementation of Health IT, software engineering best practice, HIT policy, and other domains relevant to OpenMRS, as well as the broad ecosystem of HIT, and
Provide innovative thinking and insights into the future of open source ecosystems as well as HIT.
Council membership and organization
The council shall be a permanent adjunct part of the OpenMRS community and works at the request of the OpenMRS Leadership Team.
The Advisory Council shall self-appoint a leader on a rotating term to be determined.
The Council should include individuals that represent critical areas of expertise that are relevant to the OpenMRS community.
Members shall initially be appointed for a two-year term and can be renewed as appropriate; the Advisory Council can modify the terms and appointment and reappointment process once the Council is established.
The Council shall meet regularly for at least one hour on a monthly basis, and shall provide recommendations to the OpenMRS Leadership Team through:
Direct feedback in meetings,
Written comments on OpenMRS Talk,
Individual availability to members of the OpenMRS leadership group for advice and organizational guidance, and
Asynchronous information and interaction.
The Council shall be responsible for scheduling regular meetings, establishing an agenda, and working with the Advisory Council members as needed. One or more representative of the Leadership Team shall attend each regularly-scheduled Advisory Council meeting.
In lieu of other feedback here so far, I like the charter as it stands. However, I agree with @paul that we should specifically make a call that the council should be as diverse as possible, both in demographics as well as in knowledge/skills/expertise.
I tend to agree with Darius and I glitched a bit when Michael made the comment that the council should be able do decide for itself what it should do, how it works, etc. I don’t agree. I think this is like a taskforce appointed by the leadership team. It is there to serve the Leadership and should operate under the charter by leadership. It shouldn’t be able to change that… Although, of course, it can recommend to the leadership that changes be made and then the leadership team can decide what to do. That might be closer to what Michael was thinking. In any case, I also think 1 year is less intimidating than 2 (especially if monthly calls are expected).
thanks for the comments. I am fine with a change in the terms but i think
that it will take at least a few months to get people up to speed on what
we are doing- so i think two years make sense.
good question about the modifications. I wasn’t sure how much the
Leadership Team wanted to influence the advisory team. any one else with
comments on this one? thanks
added these recommendations ( one year; recommendations for changes from the AC to the Leadership Team) in the document as suggestions. Will wait to see what other people say.
I agree with the 2 year term. The worst case scenario with a 1 year term is that no one wanted to continue after that 1 year, and you would be starting all over again every year with no experience to carry forward. With 2 years, by the second year the team will be able to use the experience with the operational plan and leadership from the first year to help guide the creation and implementation of the op plan for the following year. Ideally, we would be staggering start dates for members of the committee so that each year there was renewal for about 1/2 the committee each January. This would mitigate the risk of losing the whole committee at one time and having to start over with a whole new committee like we are doing now.
IMHO, the Leadership Team has enough on its plate running the open source project, and doesn’t need yet another thing to manage directly.
Just what are we afraid of, exactly? If we trust the Advisory Council for advice, and we trust that they have the best interests of OpenMRS at heart, why wouldn’t we trust them to manage their own terms and membership, and all the related administrative tasks?
If the LT feels that the Advisory Council doesn’t have the right people on it at some point, it should inform the Council, and it should be on them to fix the problem and get the right types of people on board. If the LT wants to suggest people to be on the Council, it can surely do that too.
I suppose this then comes down to whether the Advisory Council is something set up by the LT to help, or whether it is really a product of the community, is somewhat autonomous, and provides advice (solicited or not) to the LT. I can see both perspectives. In my more traditional view, I would prefer the former and then expectations and lines of authority are pretty clear. The latter may also work, but then how is it different from any group of people offering up advice to the LT? Would we soon get “Lobby” groups that grow out of the community and presume to have a special relationship to the LT? I think we are presuming that the community has lots of ways to help influence and assist the LT through our basic structure and operations. I think this is specifically-called out advisory committee should be directed by the LT. Wouldn’t be opposed if folks overrode me though
The point is to have an advisory council to the leadership team, not to create an autonomous self-perpetuating body.
The Leadership Team doesn’t have to actively manage this at all. It’s just that in the worst case scenario that won’t actually happen the Leadership Team needs to be able to restructure the Advisory Council.
I’m just seeing this now and I’m going to change topics a bit, but what I’d like to emphasize is that hopefully we have people on that Advisory Board to complement the core leadership skills. Specifically I think it’d be great to have individuals with
Legal experience around non-profits and open source
Fundraising experience
Management experience in large or open source organizations