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?
@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?
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 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.
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.