Thanks for starting a thread on this GSOD project, @jnsereko!
There are a many different ways to contribute to OpenMRS. You can pick up tickets, join a sprint, help with documentation, help a squad or team, etc. We also have some defined roles that community members can take on. Some are associated with and defined by squads or teams while others are more general, community roles. For instance, GSoC and GSoD have admins and co-admins. Each release usually has a Release Manager. The QA Team has a QA Lead. We also have a Software Security Lead, Community Development Lead, etc.
The idea behind this project is to create a set of volunteer guides that can help newcomers and existing community members learn about different volunteer roles, how to take one one, and what to expect. Here’s a link to the original post.
More recently, @loisnaki has been working on a guide for organizing outreach activities to attract new people to OpenMRS. As a part of those discussions, there have been some questions about these guides and how they can be used to guide volunteer follow up and retention.
This is a great time to explore the scope and approach to GSOD projects like this one, so don’t feel that you need to limit yourself to these initial scope ideas. Feel free to brainstorm new ideas and ask questions that will help you craft your proposal.
I have some ideas which we might deliberate upon and possibly incorporate into the project of Developing a Suite of Volunteer Guides.
1. Creation of WBS: To bring in a systematic manner of work I would propose that we should firstly build a visual Work Breakdown Structure (WBS) of all the work we do.
2. Creation of Team Charter or more formally an Organizational Structure with Roles & Responsibilities: Following the completion of WBS we should formulate an organizational structure wherein those charged with governance (TCWG) like managers, mentors, guides, etc. and it should also be highlighted with their roles & primary responsibilities.
3. Count of Active Personnels engaged with TCWG: I know that the structure of OpenMRS is based on contributions from Volunteers but we should also incorporate a sum-count or range of people involved with a given project and/or collaborating under TCWG, this will also be helpful for the entire community and new entrants to understand which team is under manpowered and which are the teams which can spare additional manpower in case other team are in need, not a compulsory practice but just by encouraging their team.
4. Collaborating with Outreach Team: With an established count of active personnels engaged with TCWG, being in place this data would then be used to collaborate with Outreach team so that under manpowered team can be targeted first or more emphasized.
5. Agglomeration of project work and standard operating procedures: Once the team charters are prepared, all the data spread across OpenMRS wiki or in various threads to be agglomerated in a structured manner based on WBS. A set of Standard Operating Procedures (SOP) in case not framed then it would be formulated after due communication with concerned team & TCWG’s.
These are some quick starter ideas for the project, I would appreciate your thoughts and suggestions over them.
Thank you @shahin for the informatioin. OpenMRS gives out badges in form of dtages from dev/null up-to dev/5 and specifies roles and expectations for each and eery developers stage. It does so because some roles require some skill like Initiating a maintenance release, Participating in repo management, etc This can be seen on this page
I think we should update this page to include more roles like mentors and guides
Thank you for response, I agree we can add other roles as well. Moreover, I would also like to draw your attention to the idea which I wanted to convey about my intention over the point. The idea was meant to bring to the notice of new volunteers as well as the already engaged volunteers about the chain of command and who is the penultimate responsibility center/ personnel for a specific job type. I understand we won’t be able to include details of each member but we can surely aim to include those who are actively involved in guidance, mentored, etc. and are recognized by the community members as well. Let’s discuss more about any more thoughts?
@shahin, these are good observations. Some of the roles we have are filled. Others aren’t, which is okay, too. I think part of the aim of having a volunteer guide is to give contributors an idea of the roles that are open and that they can work toward taking on.
When it comes to work that different teams or squads are doing, I hope that each team and squad project page has a list of members as well. I know that the OCL for OpenMRS Squad recently re-visited roles and responsabilities - and it looks like they’ve updated their page. Other teams and squads might need to review and update their pages.
A bit of a side note about GSoD projects and their scope. We want GSoD technical writers to have successful projects that they can complete within the given timeframe, which means that the scope needs to be clearly defined and constrained. I think there’s a balance here between what goes into a volunteer guide and what needs to be on the Wiki and/or website in order for a volunteer guide to be “good enough.” We may want to take another look at some of the Documentation tasks and see if any of them are relevant to this project and need to be prioritized. It would be great if they can be completed by the time this project begins.
Thank you @jennifer for your kind words. I agree that a thorough inspection of several other documentation tasks needs to be undertaken to actually scale down the actual scope of this project to specified & quantified (wherever possible) deliverables so that the GSoD project can be undertaken and completed in a timely, structured and satisfactory manner. Also, I am happy to tell you that I was doing the exact same thing, exploring various threads on this platform as well as on our wiki page, since past couple of days. I believe it will surely help me more to better draft the scope in a much more informed manner.
Thank you for such thoughtful comments on this issue. Couldn’t agree more about the dangers of scope creep, and how realistic expectations and solid planning can help prevent that. It seems like if this project is chosen, that getting the technical writer acquainted with the team and squad lead/stakeholders would be a key part of the ‘getting to know you’ period.
One thing I was wondering as I worked on my draft was the use of personas in this guide. I saw mention of them in the meeting notes here, and thought personas could be extremely useful, perhaps also coupled with some user surveys on volunteer background (how did they get interested in the project? What sparked/sealed their decision to become a volunteer?) and their path thus far. Would definitely love to hear any thoughts/resources/comments!
Just thought I might share this with both current members and other applicants for GSoD! I was looking at other open source project for their volunteer guides, and this one from the Fedora project seems like a possible example/inspiration/food for thought, especially since it’s Wiki based. Please feel free to reply with thoughts/comments/etc!
Good point about personas and understanding volunteer/contributor paths, @madhens. And those notes are a great find. In addition to the personas on the WIki, the Website Squad worked on personas for the website. Might be helpful to look over those and get an understanding of how the website fits into the volunteer journey.
This was a resource I found very useful in thinking about this proposal, namely key onboarding principles to center into documentation. This is all from an open source project perspective, too, so its incredibly relevant!