You may or may not be aware, but I’m the middle of cleaning up a lot of @openmrs email accounts.
It’s a huge list of people, the majority not active anymore in the community (for some years). Some people haven’t even posted in talk in more than 2 years, and still asked for their emails to be kept.
Emails are socially quite powerful. Anyone with an @openmrs email will be perceived by others as an active member of the community.
So, I’d like to define a process on who’s entitled to that, and when it would be reasonable to delete email accounts.
I understand that if the part of your job is to work with the OpenMRS community, you certainly need it. If you are considered part of the leadership as well.
Should we allow every volunteer /dev/4+ to have emails? What would be exceptions to be applied?
What about people who work with OpenMRS, but for different distros? (e.g. PIH, BandaHealth, PossibleHealth…). How much involvement do they need with the community?
Is it reasonable to delete emails accounts after 1.5 years without contact? (e.g. in talk, code or meetings, depending on the role that the person had)
@cintiadr , I agree that @openmrs emails are powerful and can be misused. You must feel free to delete the ones that are no longer active. I also agree that long time contributors(1+ yrs sounds like a fair amount of time) should only be granted the same.
I’m fine with disabling inactive accounts but it has to be after a longer time than just 1 year, I know of some devs in the past that have become inactive for over 2 years but are following the activity from a distance and become active in spots.
Shouldn’t someone be requesting for an account if they need one?
@cintiadr I also agree that the OpenMRS email accounts should be kept in the hand from the misuses.
I also agree that, the 1+ year of involvements is pretty good for requesting the OpenMRS email address.
I feel, better to create a request structure for the community members for requesting the OpenMRS email address in the Wiki. It would be better to contain these fields,
At least a valid reason for requesting the OpenMRS Email Address
OpenMRS Profile (so we can get the recent and community involvements)
The preferred email address for @openmrs.org
Backup email address (just for the information, So we can use this email to notify the user before deleting the OpenMRS email accounts in case of inactivity)
Reference from the Dev/4 or Dev/5 people (it can easily restrict the unwanted requests)
If we came up with a preferred structure for the request, then I could create a Wiki Documentation about the process for requesting OpenMRS email address
I believe there is a quota on emails (not too tight, certainly not enough to automatically give everyone an email), which is why we adopted an opt-in model. Our current model has been to grant OpenMRS emails (i.e., an account within our G Suite) to people who need it, which is typically when they are representing OpenMRS in some form (administering a program, helping with help desk, helping set up an OpenMRS conference, taking on leadership roles, etc.). While dev stages are more about technical skill and not really relevant, if we decided to adopt & use om.rs/stages then we could – for example – include G Suite account creation with achieving /omrs/2 or above.
I think @suthagar23’s suggestion for information needed is good; however, with rare exceptions, I think the G Suite username (and thereby the email username) should always match the OpenMRS ID (far easier for us to manage/script). If someone wants foobar for their @openmrs.org email username but has foo.bar for an OpenMRS ID, then I think we should work to get them the foobar OpenMRS ID (even if it means reclaiming a previously used one that has gone unused).
As for removing people from G Suite, I think it should follow along with OpenMRS ID – i.e., when your OpenMRS account is retired, so goes your G Suite (and email). As a start, I would think that any account that had not been used for 2 years or more could be retired. Ideally, we’d send an email notification out automatically at 18 months of no activity and another a week before 2 years have been reached with instructions on what is required to keep their account from being deleted. G Suite/email removal would just parallel retirement of the OpenMRS ID.
I don’t know how possible that is, to be fair. I don’t know if that would break crowd/jira/confluence and everything else. After I do the cleanup we can try to see if that’s possible.
I didn’t mean to imply that we would need to do this perfectly; rather, in the case where foobar is no longer used (no activity > 2 yrs or disabled), then we’d change its email and reset the password and retire foo.bar (i.e., the person would one say stop using foo.bar and start using foobar, inheriting its history. If foobar OpenMRS ID was unclaimed, we’d just have them sign up for it and retire their old account. Any ability to archive the legacy content for foo.bar to (old) foo.bar or delete/merge accounts would be nice-to-have, but not necessary.
Going forward, we’d try to match G Suite users to OpenMRS IDs. Ultimately, it would be intuitive that foobar at openmrs.org can be found in Talk/wiki/jira/etc as foobar.
I just have a look into that Doc. So we need to create a new ticket in the JIRA for requesting OpenMRS emails as it said. I just encountered some diffrent idea on this,
Why don’t we use a single JIRA Ticket for this purpose, and ask the users to claim and provide their details as a comment to proceed? So we can able to reduce the redundant number of tickets for this requests.
Is it okay to show the backup email address and the referral person for the public view? I felt better to do it behind the scenes since someone doesn’t like to have it in public due to the privacy.
BTW why don’t we do this through the HelpDesk emails like we have now? So the user should need to add those details in the Helpdesk emails to get the OpenMRS emails.
I like @suthagar23’s suggestion to do this via helpdesk instead of JIRA, though I don’t feel very strongly about that. (We should, however, not make people’s backup email addresses public. (In JIRA that would mean making the visibility “Private & Reporter” I think.)
I would present “in the community for one year” as a guideline, and I actually don’t think it lines up well with the idea that this is a tool. E.g. imagine someone is helping to organize this year’s conference and needs an email for some related reason, but they’ve only been around for a few months? And further it seems like “Reference from the Dev/4, Dev/5 or leadership person” should actually cover the intention here, right?
How about we rephrase
Volunteers need to be part of the community for at least a year before requesting it.
as instead:
You should be a well-known member of the community, or have a reference from a long-standing community member, to request an email address. (Give details in the request.)
I would also be less optimistic and rephrase
Exact details on account inactivation (both OpenMRS ID and Email) will be defined soon.
The way we are currently handling tickets is much easier if there’s a new ticket per request. Otherwise we won’t be actioning on them the same way.
I prefer JIRA because 1) helpdesk has zero visibility of work that has been done and 2) we’ll have to migrate anyway in a year, and I’m not sure I’ll be bothered moving the older tickets. But I’ll agree with the visibility of the ticket, and changed the page.
For all the other points, sounds pretty sensible to me and I did those changes. I’m quite happy with the result.
