[Marketing] Social media access policy proposal

josephgayoso commented

2023-05-01 01:34:10 +00:00

(Migrated from gitlab.com)

The goal of this policy is to document and streamline who should get access to the Fedora Project social media accounts. The policy should protect against spreading account access too broadly by preventing access of accounts to too many people or to individuals who need to be shown as trustworthy. By outlining a process, we help to make it impartial, transparent, and clear to those who my want to contribute through social media content.

One of the first pieces of feedback we got was to leverage the Marketing Team as a way of vetting potential candidates for social media access. That is why the process for joining, leaving, and adjusting the Marketing Team and its structure is part of this policy.

First you have to join the Marketing Team, then you have to qualify for nomination, and then you're nominated for access to a specific account and the Mindshare Committee will make a decision.

Please approve this policy or let us know how we can adjust so that we can start looking for and nominating contributors to manage more social media accounts.

HackMD of the proposal

To become a member of the social media access group:

You must have been involved in the Fedora Project for 9 months at least.
You must be a member of the Marketing Team for at least 3 months.
There must be a need for someone to gain access to a social media account as judged by the Marketing Team or Mindshare Committee.
Then someone from the Marketing Team would nominate you to be added to the social media group and the Mindshare Committee would vote on that.

How to join the Marketing Team

In order to join the Marketing Team:

You must have been collaborating with the Marketing Team for at least a month.
After that, someone in the team can nominate you to join the team.
Your nomination will be presented to the team, and if no one objects to to your addition within 1 week, you will be admitted to the team. At that point you will be added to the Marketing Team FAS group. If an objection is raised, then the team will discuss further to try to reach consensus.
In order for a team member to be removed from the Marketing Team, a 2/3 vote must pass to remove the person in question. At least 1/3 of all team members must vote to reach a quorum.
Every year after the April release of Fedora Linux, all members of the Marketing Team will be contacted to confirm their continued membership. If there's no response after multiple attempts, or if they decline to stay on the team, those members will be marked inactive by removing them from the Marketing Team FAS group and the social media access group (if relevant).

How to change the rules for the Marketing Team

Team member suggests a change to the rules, policy, or structure.
Team votes on the change and passes with a majority vote. A minimum of 1/3 of the Marketing Team must vote in order for the motion to be valid.

# Social Media Access Policy Proposal The goal of this policy is to document and streamline who should get access to the Fedora Project social media accounts. The policy should protect against spreading account access too broadly by preventing access of accounts to too many people or to individuals who need to be shown as trustworthy. By outlining a process, we help to make it impartial, transparent, and clear to those who my want to contribute through social media content. One of the first pieces of feedback we got was to leverage the Marketing Team as a way of vetting potential candidates for social media access. That is why the process for joining, leaving, and adjusting the Marketing Team and its structure is part of this policy. First you have to join the Marketing Team, then you have to qualify for nomination, and then you're nominated for access to a specific account and the Mindshare Committee will make a decision. Please approve this policy or let us know how we can adjust so that we can start looking for and nominating contributors to manage more social media accounts. [HackMD of the proposal](https://hackmd.io/@fedora-marketing-team/H1GK9K2m3) ## [Mindshare Policy Proposal] How to get social media access To become a member of the social media access group: 1. You must have been involved in the Fedora Project for 9 months at least. 2. You must be a member of the Marketing Team for at least 3 months. 3. There must be a need for someone to gain access to a social media account as judged by the Marketing Team or Mindshare Committee. 4. Then someone from the Marketing Team would nominate you to be added to the social media group and the Mindshare Committee would vote on that. ## Related info ### How to join the Marketing Team In order to join the Marketing Team: 1. You must have been collaborating with the Marketing Team for at least a month. 2. After that, someone in the team can nominate you to join the team. 3. Your nomination will be presented to the team, and if no one objects to to your addition within 1 week, you will be admitted to the team. At that point you will be added to the Marketing Team FAS group. If an objection is raised, then the team will discuss further to try to reach consensus. 4. In order for a team member to be removed from the Marketing Team, a 2/3 vote must pass to remove the person in question. At least 1/3 of all team members must vote to reach a quorum. 5. Every year after the April release of Fedora Linux, all members of the Marketing Team will be contacted to confirm their continued membership. If there's no response after multiple attempts, or if they decline to stay on the team, those members will be marked inactive by removing them from the Marketing Team FAS group and the social media access group (if relevant). ### How to change the rules for the Marketing Team 1. Team member suggests a change to the rules, policy, or structure. 2. Team votes on the change and passes with a majority vote. A minimum of 1/3 of the Marketing Team must vote in order for the motion to be valid.

funnelfiasco commented

2023-05-01 14:17:14 +00:00

(Migrated from gitlab.com)

Thoughts!

Let's specify a time instead of saying "the allotted time frame"
It doesn't need to be specified in the policy necessary, but we should give some consideration of the mechanics of 1. determining inactivity and 2. noticing that someone has been inactive. Is someone responsible for conducting a check on a regular basis, or is it more of a "oh hey, I notice so-and-so hasn't been around a while?"

Thoughts! * Let's specify a time instead of saying "the allotted time frame" * It doesn't need to be specified in the policy necessary, but we should give some consideration of the mechanics of 1. determining inactivity and 2. noticing that someone has been inactive. Is someone responsible for conducting a check on a regular basis, or is it more of a "oh hey, I notice so-and-so hasn't been around a while?"

josephgayoso commented

2023-05-02 00:22:48 +00:00

(Migrated from gitlab.com)

First, for the time allotted, does 1 week work?

Second, here are my thoughts for determining when is the last time someone was inactive. I was going to outline a big complicated process for finding out when someone was inactive and then pinging them a few times to confirm whether they would like to remain a part of the team, but I think there's a simpler way.

Since joining the Marketing Team is so low stakes and there isn't even that much that a non-contributor couldn't do, I think we can have an annual clean up / confirmation of membership. Once a year, maybe starting next April after the Fedora release, we pull up the Marketing FAS group, ping all of them, and ask them to confirm their membership in the team for another year. If they respond, they stay in the team. If they don't, then they're removed from the FAS group and any social media access they may have. Maybe we can do like 2 pings and call it at that point. Does that work?

I know the FAS group is currently kind of loaded up, but after one year I expect us to be able to trim it down, and then it should remain reasonably sized after that.

Third, should I make the edits we decide to the HackMD or the actual ticket itself?

First, for the time allotted, does 1 week work? Second, here are my thoughts for determining when is the last time someone was inactive. I was going to outline a big complicated process for finding out when someone was inactive and then pinging them a few times to confirm whether they would like to remain a part of the team, but I think there's a simpler way. Since joining the Marketing Team is so low stakes and there isn't even that much that a non-contributor couldn't do, I think we can have an annual clean up / confirmation of membership. Once a year, maybe starting next April after the Fedora release, we pull up the Marketing FAS group, ping all of them, and ask them to confirm their membership in the team for another year. If they respond, they stay in the team. If they don't, then they're removed from the FAS group and any social media access they may have. Maybe we can do like 2 pings and call it at that point. Does that work? I know the FAS group is currently kind of loaded up, but after one year I expect us to be able to trim it down, and then it should remain reasonably sized after that. Third, should I make the edits we decide to the HackMD or the actual ticket itself?

josephgayoso commented

2023-05-02 00:23:50 +00:00

(Migrated from gitlab.com)

mentioned in issue fedora/marketing/marketing-planning#19

funnelfiasco commented

2023-05-02 11:48:30 +00:00

(Migrated from gitlab.com)

First, for the time allotted, does 1 week work?

That seems reasonable to me. I wouldn't go any shorter than 1 or longer than 2.

Second, here are my thoughts for determining when is the last time someone was inactive.

This makes sense. We do a similar "keepalive" for Spins each release to make sure there's still someone there. I think a process like that works fine here.

Third, should I make the edits we decide to the HackMD or the actual ticket itself?

For the first part, I'd make it in both, that way whichever one people look at, it's right. As a matter of style, I'd document the process for removing inactive contributors separately from the policy. But if you want to combine them, that's fine. I'd again put the edits in both places for clarity.

> First, for the time allotted, does 1 week work? That seems reasonable to me. I wouldn't go any shorter than 1 or longer than 2. > Second, here are my thoughts for determining when is the last time someone was inactive. This makes sense. We do a similar ["keepalive" for Spins](https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/) each release to make sure there's still someone there. I think a process like that works fine here. > Third, should I make the edits we decide to the HackMD or the actual ticket itself? For the first part, I'd make it in both, that way whichever one people look at, it's right. As a matter of style, I'd document the _process_ for removing inactive contributors separately from the _policy_. But if you want to combine them, that's fine. I'd again put the edits in both places for clarity.

josephgayoso commented

2023-05-03 01:27:57 +00:00

(Migrated from gitlab.com)

changed the description

josephgayoso commented

2023-05-03 01:29:18 +00:00

(Migrated from gitlab.com)

Enter the change in the ticket and the HackMD.

As a matter of style, I'd document the process for removing inactive contributors separately from the policy. But if you want to combine them, that's fine.

I kept it together because it isn't that much longer than what was there before.

Enter the change in the ticket and the HackMD. > As a matter of style, I'd document the *process* for removing inactive contributors separately from the *policy*. But if you want to combine them, that's fine. I kept it together because it isn't that much longer than what was there before.

justwheel commented

2023-05-03 04:46:58 +00:00

(Migrated from gitlab.com)

changed health status to needs attention

changed health status to **needs attention**

justwheel commented

2023-05-04 20:26:12 +00:00

(Migrated from gitlab.com)

Thanks @josephgayoso for opening this discussion here.

My first thought is that the "How to get social media access" part is relevant for a Mindshare policy. But for guidance on how to join the Marketing Team and how to change the rules for the Marketing Team seems very specific to the Marketing Team. Is there a good reason to codify this language at the Mindshare Committee policy, or should that exist as its own independent documentation for the Marketing Team? I lean towards the second option.

Otherwise though, what is described here looks good to me, and I know we also have been deliberating on this quite a while over on Fedora Discussion. So, no major objections from me on what is written here, but my feedback is more on delivery and who should own which parts of what is written here.

Thanks @josephgayoso for opening this discussion here. My first thought is that the "How to get social media access" part is relevant for a Mindshare policy. But for guidance on how to join the Marketing Team and how to change the rules for the Marketing Team seems very specific to the Marketing Team. Is there a good reason to codify this language at the Mindshare Committee policy, or should that exist as its own independent documentation for the Marketing Team? I lean towards the second option. Otherwise though, what is described here looks good to me, and I know we also have been deliberating on this quite a while over on Fedora Discussion. So, no major objections from me on what is written here, but my feedback is more on delivery and who should own which parts of what is written here.

josephgayoso commented

2023-05-05 00:18:10 +00:00

(Migrated from gitlab.com)

I added the part about how to join the Marketing Team because we wanted the step of joining the Marketing Team to be part of how we select people for social media access. If we want I can take it out no problem.

Thinking about it more, I imagine that this policy will then live somewhere in the Mindshare documentation and would thus be harder to change should we want to do something different in the Marketing Team. For that reason, I'll rearrange the proposal so that you know exactly what is the policy for Mindshare and what is Marketing stuff (which would just be context for the decision).

I added the part about how to join the Marketing Team because we wanted the step of joining the Marketing Team to be part of how we select people for social media access. If we want I can take it out no problem. Thinking about it more, I imagine that this policy will then live somewhere in the Mindshare documentation and would thus be harder to change should we want to do something different in the Marketing Team. For that reason, I'll rearrange the proposal so that you know exactly what is the policy for Mindshare and what is Marketing stuff (which would just be context for the decision).

josephgayoso commented

2023-05-05 00:20:12 +00:00

(Migrated from gitlab.com)

changed the description

josephgayoso commented

2023-05-19 18:17:33 +00:00

(Migrated from gitlab.com)

Just following up on this. Is there anything more that's need from the Marketing Team to put this to a vote?

justwheel commented

2023-05-19 22:36:04 +00:00

(Migrated from gitlab.com)

I can make a MR with the proposal to our docs repo. Is the HackMD pad up to date?

I can make a MR with the proposal to our docs repo. Is the [HackMD pad](https://hackmd.io/@fedora-marketing-team/H1GK9K2m3) up to date?

josephgayoso commented

2023-05-20 00:34:47 +00:00

(Migrated from gitlab.com)

Yes, it is. I mirrored the changes to the HackMD.

justwheel commented

2023-06-01 21:52:44 +00:00

(Migrated from gitlab.com)

@josephgayoso After the release party wraps, I will open a new Merge Request with the policy proposal as written. Or alternatively, you could open the MR directly, or I could teach you how to open a MR.

In the meantime, I created a new docs module for Mindshare policies in https://gitlab.com/fedora/mindshare/docs/-/merge_requests/5. My intention is that it will make it easier and more clear for everyone about what the policies, bylaws, rules, etc. are for the Mindshare Committee. The social media policy should be distinguished from "normal" docs that we have in the repo.

@josephgayoso After the release party wraps, I will open a new Merge Request with the policy proposal as written. Or alternatively, you could open the MR directly, or I could teach you how to open a MR. In the meantime, I created a new docs module for Mindshare policies in https://gitlab.com/fedora/mindshare/docs/-/merge_requests/5. My intention is that it will make it easier and more clear for everyone about what the policies, bylaws, rules, etc. are for the Mindshare Committee. The social media policy should be distinguished from "normal" docs that we have in the repo.

justwheel commented

2023-06-01 21:53:04 +00:00

(Migrated from gitlab.com)

assigned to @jwflory

justwheel commented

2023-06-01 22:01:53 +00:00

(Migrated from gitlab.com)

mentioned in issue fedora/marketing/marketing-planning#55

justwheel commented

2023-06-11 15:09:15 +00:00

(Migrated from gitlab.com)

mentioned in merge request docs!110

josephgayoso commented

2023-07-10 03:39:31 +00:00

(Migrated from gitlab.com)

mentioned in issue fedora/marketing/marketing-planning#64

josephgayoso commented

2023-09-01 17:55:09 +00:00

(Migrated from gitlab.com)

mentioned in issue fedora/marketing/marketing-planning#80

josephgayoso commented

2023-09-05 01:59:44 +00:00

(Migrated from gitlab.com)

mentioned in issue fedora/marketing/marketing-planning#79

justwheel commented

2025-07-16 13:09:45 +00:00

(Migrated from gitlab.com)

unassigned @jwwheeler

justwheel commented

2025-07-16 13:11:06 +00:00

(Migrated from gitlab.com)

@amoloney @ekidney @lbazan @sumantrom @gridhead Please take a look at this thread. I think this is an excellent ticket to revisit, as it is also not related to events and represents a bigger picture concept for how we approach social media.

This could also connect to how the Marketing Team rep brings value to the Mindshare Committee, once we identify that rep.

@amoloney @ekidney @lbazan @sumantrom @gridhead Please take a look at this thread. I think this is an excellent ticket to revisit, as it is also not related to events and represents a bigger picture concept for how we approach social media. This could also connect to how the Marketing Team rep brings value to the Mindshare Committee, once we identify that rep.