[Issue 221] Open source group kick deliverable specification draft

[sumiat]

first draft of the deliverable specification document

Summary

Fixes #221

Time to review: 15 mins

[lucasmbrown-usds]

I understand we're downscoping this quite a bit, so I'm very open to having a conversation around what we want to keep in and move out of the definition of done.

This to me feels like we would want to rename it as something like, "Communication tools 2.0" or something like that. Or "Open source comms tools"?

With the original proposal for Open Source Group kickoff, I think we were hoping to have the first of an ongoing set of public, open source meetings on the project, setup a mailing list for those participants, etc. I'm okay if we defer that to another 30k, but we should probably update the name of the 30k for clarity.

[sumiat]

With the original proposal for Open Source Group kickoff, I think we were hoping to have the first of an ongoing set of public, open source meetings on the project, setup a mailing list for those participants, etc. I'm okay if we defer that to another 30k, but we should probably update the name of the 30k for clarity.

That makes sense @lucasmbrown-usds! We can definitely rename it, and I would love to understand what original expectations were. We may be able to set up a public calendar, and/or set up the first meeting(s) or welcome session. I was more conservative on what we could get done because I wanted to wait until the Open Source Evangelist had started.

[widal001]

I really like how you narrowed the focus of this 30k deliverable spec to focus specifically on finalizing comms tool implementation and onboarding open source community members!

I left a bunch of suggestions throughout, but I think the major ones are listed below:

• As we talked about last week, we should rename this deliverable. Maybe "Open source onboarding process" or "Open source group onboarding"?
• We should add public wiki and google group to the scope of this 30k
• We should set some explicit targets in the DoD for the minimum number of folks onboarded to each of our public-facing tools to call this "done" -- that's the best test for whether or not we have a repeatable process.
• Also, there are a couple of sections of the template that still need to be filled out or expanded, namely:
  • Translations
  • Security considerations
  • Not doing - I just thought it could be good to explicitly state that we won't be holding the first open source group meeting.

We can go through these updates in our next 1:1!

[widal001]

Can you update this to match the summary table in the other deliverable specs?

[sumiat]

done! Billy, I wasn't sure if I should mark you as a product owner or as another document owner since you would be contributing to this document too. Feel free to change it.

[widal001]

This isn't as relevant if we'll be moving these into the public wiki!

[widal001]

I do think we want Google Group and public wiki in scope

Instead I would say, we're not starting a recurring set of meetings with an open source group, and we're not kicking off the participant advisory council in this 30k. This will simply be focused on finalizing our open source communication tools and creating an onboarding process.

[sumiat]

I will include this in the security section but I believe we will need to get security approval to use Google Groups and maybe Zoom since they will be collecting email addresses of users. Slack and wiki are used currently so I assume they are OK but we may need to check on that with the Security team too

[widal001]

Let's work on this together the next time we meet! I'll jot down a few notes for us to discuss:

Definition of Done

I like what you have, but I think we can also pull from the comms platform DoD specifically this section:

- [ ] The following conditions have been satisfied for all tools:
  - [ ] At least 3 members of the general public have been onboarded.
  - [ ] New members of the public can be onboarded to the tool for no cost to the user in a process that takes less than 2 days.
  - [ ] Services are accessible to all people on the HHS network, public internet, and _preferably_ the White House network and most or all agency networks
  - [ ] Onboarding instructions for new users are clearly and accessibly documented in a public place.
  - [ ] Instructions for the internal team that assists with onboarding new users are clearly and accessibly documented in our internal wiki.
  - [ ] Code for managing and deploying these services is deployed to `main` & PROD (if necessary)
  - [ ] An ADR has been recorded which documents the tool chosen and the reasons for selecting it

And I think we want to make sure that all of the following tools are chosen and implemented for the project.

• Slack
• Google group
• Public wiki
• Zoom

[sumiat]

Added some of your comments into the spec!

[sumiat]

Closing this PR as I moved the deliverable spec to the public wiki and will publish from there.