Should we have a separate role for the members of the team in the FreeBSD Discord Channel? Especially since in #1 we decided the #community channel would be the main place for comms.

Edit to say: admin perms wouldn't really even be necessary, just maybe a different color for organization and easy identification.

• Create community role in FreeBSD Discord
• Set role icon: @freebsdhelp avatar for now
• Update onboarding to include adding team member to community discord role

Quoting from Mission and Purpose: ...highly-effective community organizing team and capability...

• What does it mean to be 'highly effective'?
• What capabilities are desired as priority?
• In other words, how do we know when we're successful?

Quote: ... social media channels are only the first test-case...

• Any specific channels we're targeting as a start?
• What are we 'testing'?

I like the points made here: https://keepachangelog.com/en/1.0.0/
We could aim for monthly updates instead of "versions" and we could probably stick to "added", "changed", and "removed" categories.

There's a large number of duplicate lines in the name files. We could either merge them into one or revise what they discuss.

• guidelines.md contains all updated content from freebsdhelp.md
• all duplicated information removed from freebsdhelp.md

• IRC
• Discord
• Somewhere else?

It might require an update to the FreeBSD style(9), as there are probably a few things that we haven't dealt with well yet. We can then work on opening a PR for the LLVM project and writing a .clang-format for our projects. Hence:

• Check style(9) and see if it requires an update - in respect of the standard, specifically.
• Fork llvm/llvm-project and add our style to predefined styles.
• Add .clang-format to our projects and run some tests.
• Open a PR and submit our changes to the LLVM project.

Once we decide the primary Discord (FreeBSD or BSDLabs), implement and enable GitHub notifications so they're announced there so its easy for people to stay up to date

Depends on #1

Edit Decision: Yes, always be recruiting.

@jhfoo asked

when is your recruitment closing? Feels only then can we have an inclusive convo and

How many are you looking to bring in? after suggesting, regarding goals, roadmap:

Before we get too invested in tactics we should think about what we are trying to accomplish, per the 4 points listed in readme

This raised the question of whether after this initial round of recruiting, whether we might want to have an 'always open' recruiting process/position, so that interested folks could get in touch and apply if they wanted to.

This would look something like, and require:

• Define and write an 'ideal role description'
• Publish role description and call to action $somewhere...
• With a link or form to submit an application to join the team
• Allow people to include relevent details along with that app (motivation, skills, cover paragraph, etc)
• Doc decision and link to landing page in CHANGELOG.md

Depends-On: #18

This issue is open for brainstorming ideas to improve the FreeBSD Discord experience, especially for newcomers and beginners. Please share and discuss your ideas and feel free to edit this comment (or ping me to do so if you lack permission) to add/edit/remove an item to the following checklist.

I request you research and take a look at other well-formed communities to see how they've grown and what they've done to shape their community on Discord.

IDEAS / BRAINSTORM

• Add more beginner-friendly channels for newcomers.
• Further categories existing channels to better target their specific audience.
  e.g. dividing administration and development to separate categories.
• Add a welcome channel to let new members introduce themselves and to break the ice.

Thank you so much, @bsdlabs/everyone.

While working on #18, I realized we have some redundancies in guidelines.md and playbook.md- to me, it seems like playbook.md could be a subsection in guidelines.md. How do we feel about this?

Currently the playbook (freebsdhelp.md) has a "DO" item:

DO tag tweets with a ^XX suffix, where XX are your initials or a similar unique tag

The original rationale for this was so the team could track and see who tweeted what.

Someone tweeted Y'all should sign your tweets so we know who sends them, after a few untagged tweets, so it raises the question again (as its obviously important enough for someone to mention), to discuss and decide officially as a team, though there's no rush.

Here are some Pros/Cons I can think of for starters:

Pros

• Each team member gets credit
• We all know who did what
• We can search for our prior tweets by tag

Cons

• Takes up extra space
• Dilutes the “one personality” brand
• No real extra value

So- for the weekly segments I write for twitter, I'd like to upload them at the end of each month for people to access and read without scrolling all the way down in our feed. Should I:

Open a new repo?

Pros:

• separate from main community repo
• slightly more organized

Cons:

• Might be harder to find if someone came here from the twitter bio
• Feels a little fragmented, personally

Create a folder under community?

Pros:

• Easy to find
• seems to make sense categorically

Cons:

• Don't want to make a habit of pushing lots of stuff into the community repo
• Would require some extra folders to lay groundwork for other twitter segments

Any suggestions/comments/concerns? :)

As discussed on the FreeBSD Discord server, promoting major releases and educating community members on what's improved could be effective for catching up, advocating the project, representing the project's core values broadly, and developing the community.

We need to establish a sustainable procedure to host and finally archive formally scheduled live streams. On the other hand, community members are always welcome to stream on Discord (preferably by letting admins know beforehand - to avoid collisions), and there'll be no need to archive them.

The following checklist might take some time to finish, and any assistance you can provide would be greatly appreciated.

• Develop a scheduling strategy (Release date 2021-12-06 Unknown time)
• Hands up for promoting the event from now onward on Twitter, IRC, elsewhere ...
• Dedicate a Discord channel for Release & Upgrade Party
• Enrol Release & Upgrade Talks Speakers (might require an online form for accepting/reviewing applications)
  • This needs an owner champion
• Decide on the streaming platform and the streaming procedure (YouTube, Twitch, Discord, etc. - and integrations if any required)
  • Setup Discord music bot for background/ambient music
  • Probably need an MC/DJ for this, but full time not needed
• Document all of the above
  • Note, this item is to document what we do this time, so we can do it consistently in the future (and not have to repeat this issue)

We have some people on IRC that don't use Discord, and bsdlabs has had a presence on IRC for a long time before Discord.

We'd like to setup an IRC/Discord bridge between the two comms channels, particular as we decided that FreeBSD's Discord #community channel will be our main comms place, with BSDLabs Discord a comms place for broader bsdlabs discussions

• Review and shortlist from List of GitHub Repositories matching Discord/IRC in Python
• Evaluate Discord/IRC Bridge Bots. We prefer Python, but we'd consider well-maintained bots with special features.
• Determine hosting location (Touch base with @Rodrigo-NH. He hosts our current bsdlabs/bsdlabs.io/bsd.io services/apps/PoC's)
• Determine setup and configuration, with server/channel to server/channel mappings (1:M, M:M, etc).
• Document Bridge setup

• Add to organization
• Add to @FreeBSDHelp Twitter Team
• Mitchell: Onboarding steps done

Document the steps you go through to setup your 'team twitter' environment (for your OS), and document it in a new section in freebsd.md for 'Getting Setup'

Discord has a dedicated landing page for Open Source projects and communities that use Discord

• Evaluate acceptance criteria
• Produce gist for review
• Fork https://github.com/discord/discord-open-source and produce a PR for submission ❤

The original introduction was specifically about growing the freebsdhelp Twitter team.

This however, was merely the first practical initiative for the broader goal.

Accordingly:

• Write a new introduction for the broader "community/communications capability"

References #7

Find the best course of action:

1. make the readme the de-facto landing page, including:

• team overview
• call to action (will ask around for what specifically this could be)

2. create a separate .md specifically for twitter, containing the points above.