Working Group Upgrades!

[cuevasm]

Hey all, Working Groups were formally introduced late in 2022 and have since become a common way for contributors in the Stacks ecosystem to collaborate on various efforts. We’ve seen Working Groups focused on everything from topics and interests to specific technical efforts like sBTC, to collections of people with a particular skill set. It’s been great to see and we thank each of you that has participated in a Stacks Working Group.

This resource will propose additional structure (and resources) to Working Groups with the goals of:

• Increasing the discoverability of WGs, with the hopes more potential contributors (as well as the general community and public) can easily identify and learn more about WGs relevant to them.
• Enforcing consistency around how WGs communicate progress as a means to raise visibility on the results and impact of WGs
• Further bolster a culture of accountability within WGs

If all that sounds lofty, don’t stress it. At the end of the day, we’re recommending a few small changes to how WG leads operate today and we’re even committing folks from the Stacks Foundation to help drive these changes early on. With a few tweaks, we believe we can better highlight the amazing work that is happening and draw more talented people to our cause of activating the Bitcoin economy.

Proposed Working Group Changes:

• All Working Groups need to fill in a complete brief and receive at least 15 ‘hearts’ on the Github discussion outlining what they intend to take on.
  • Why: A complete brief and a minimal level of community buy-in is a clear indicator the WG team is serious and will setup WGs for success.
• All WG leads commit to regular status updates posted on Github (details in the checklist).
  • Why: It’s key to an open-source ecosystem that individuals and WGs are communicating about their progress. This allows folks like the - Ecosystem Project Manager and other leads to better coordinate across WGs, make helpful connections, prevent duplicative work, and identify when WG deliverables might be at risk.
  • Why: Showing our incredible progress to the rest of the world becomes much easier when all WGs are sharing updates consistently. This energizes many key audiences for the project and sends important signals about progress.
• WGs commit to sharing a process by which new contributors can join, along with their requirements for doing so.
  • Why: WGs should have the discretion to build the team they need, but we also need to be sure paths to join are illuminated and transparent. This will provide clarity for potential contributors and make it more clear where talented people can help.
• Working Groups commit to a meeting/communication schedule and to establishing a fitting communication channel for ongoing async collaboration.
  • Why: Work can’t happen without regular communication. Each WG has the freedom to decide what channel and cadence works best for them. Regular communication greatly increases the chances of a WG successfully delivering on its goals.

You can see the updated list of things WG leads would be responsible for below.

How the Stacks Foundation will help

• Automated and personal reminders for WG leads will be provided
• Templates and recommendations will be offered where there are expectations for written updates
• Our team will flag to the community if/when a WG is not meeting the expectations so that a discussion about how to proceed can be had
• We’ll compile updates from across WGs and package to post and amplify on channels from the forum to Twitter and everything in between
• We’ll offer an initial feedback session on your WG idea or proposal if you would like it. This is not required, but we’re happy to offer tips based on what we’ve seen, help you best articulate the goals and work ahead for the community, suggest other potential members, and connect you with resources that may be helpful if your WG moves forward.

Having been involved with so many WGs, our team has a unique perspective on the mechanism and is excited about how these updates can take WGs up another level and grow our collective bandwidth. We’d love to hear your feedback on these updated expectations below over the next 10 days. After that, the goal will be to make these new expectations live by October 1st, 2023 at which point we’ll reach out directly to WG leads to support them.

Rollout Schedule:

• Today - New expectations proposal and checklist posted for feedback (leave comments below)
• September 25th - Final day for feedback on updated expectations
• October 1st - New expectations go into effect, Stacks Foundation support as outlined above begins
• October 15th - This WG index will be fully refreshed and populated with all WGs and their first or second update

[cuevasm]

Working Group Lead Checklist

For reference, here would be the full set of activities WG Leads would be responsible for:

One-time (not new, but added a couple required bullets):

• Fill in a WG brief, complete with the following key information:
  • Objective & Scope - why is the group being created, what is the problem it’s addressing, what is it trying to achieve, is there anything that is explicitly out-of-scope for the group, etc.
  • Deliverables - what should the group be bringing back to the community once completed
  • Timeline - when is the group expected to have it’s deliverables complete
  • Lead - who will be responsible for leading the group and ensuring it completes its designated assignment
  • How contributors can connect with the WG - Explain who you are looking for and how contributors can ask or apply to join
  • Roles and Responsibilities - Use the RACI model (provided to WG leads) to define roles and responsibilities within the WG.
  • Meeting schedule and format - Generally, WGs should be meeting regularly. Depending on the nature of the group, this can look very different so there are no hard rules here, however, what you decide on should be communicated and consistently done. (All meetings, recurring or otherwise, should be added to https://stacks.co/events)
  • Additional Context - Any additional context that might be important for the group including previous conversations on the topic, dependencies on or with other work going on, a special update cadence, etc.

Bi-weekly (every other week, 15-minute commitment)

• WG leads must post a progress update at least once every other week as a comment on the Github discussion thread. More frequent updates or updates when something very notable happens is also welcomed, bi-weekly is a minimum. These are simple updates that should take no longer then 10 or so minutes to produce and should not be complicated or heavy, we're just looking for better consistency.

Example bi-weekly updates:

• https://github.com/orgs/stacks-network/discussions/483#discussioncomment-6259915
• https://github.com/orgs/stacks-network/discussions/470#discussioncomment-3880166
• https://github.com/orgs/stacks-network/discussions/465#discussioncomment-4772467
• https://bitcoinwrites.com (this is an example of the sBTC Resident going above and beyond expectations. I share it here just for reference for what could be done in certain cases where a few WGs are working on a major effort like sBTC). This takes Andre about an hour a week and is well beyond the scope of what's required here.

Monthly (15-25 minute commitment):

• Reflect on the original WG brief, update only if needed. It is natural for WG goals and deliverables to shift as the group learns more. This is great, but we need to make sure that the most current intent of each WG is always being reflected publicly and the community is abreast of the changes (especially if changes may impact the work of others).
• Review calendar information and ensure any changes to WG meeting schedule are reflected.
• Review new applicants for the WG and communicate acceptance or denial, along with rationale.

Example:

• The Bitcoin Summer group has a simple application up for folks interested in joining the WG

Quarterly (15-30 minute commitment):

• Provide an update to the broader community via a Stacks Townhall
• Work with the Stacks Foundation to compile a written progress update on the WG including what was accomplished, what is next, and what resources or support is needed going forward.

Example:

• Various WG leads/members joined the last townhall and were guided through a discussion and set of updates so the broader community could enjoy in this format.
• Elsewhere, this update from Andre could very well be used as a template for the monthly or quarterly update expected from a WG lead. Obviously, all WGs are in different places and have different scopes, so what is right for each group will vary. You'll be guided where you are unsure, all that matters is that you get the important things out!

The new requirements for updates translate into less than an hour of 'new' work for WG leads. Many WG leads are, however, doing some form of updates, so for them, this will not add new time.

Again, templates and guidance will be provided to leads.

[alexlmiller]

These changes all sound great to me and I’m very supportive.

in particular I think the clear accountability and buy in standards, coupled with the foundation folks working to make sure they’re lived up to will be great for making effective working groups.

[muneeb-ali]

I'm big fan of public updates and increased accountability. If open-source contributors sign up for certain responsibility then it only makes sense to hold them accountable; this is how open-source projects evolve and mature. Making all information easily discoverable for the public helps a lot of things. More people can discover what is going on in various WGs, engagement from broader community (not just people who can write code) goes up etc.

[jcnelson]

Hi @cuevasm, thank you for taking the time to write this proposal! I agree with @muneeb-ali that public updates are a good thing for open source projects, in part because the beget accountability and responsibility in addition to improving project discoverability.

If I may, I'd like to propose an alternative working group spec that I hope will provide the same benefits, but with far less effort. The reason I'm having a hard time accepting this proposal is because the status quo for WGs today is to post daily updates on Discord (a 30-second daily effort), and this small thing has proven to be a mighty challenge to do consistently. This feels like even more work, and thus even more prone to lapsing.

Ideally, WG members wouldn't need to undertake any effort at all, and the WG lead would only need to undertake minimal effort every two weeks (just a brain dump of what's going on) and show up for one additional quarterly meeting. I went ahead and made a Nakamoto WG Github gist to demonstrate what I had in mind. I believe includes all of the pertinent information for the WG I lead, and it appeals to me is because it provides a simple, low-effort but high-impact way of posting biweekly updates publicly (e.g. I just edit the gist) without any other WG member's involvement.

Please let me know what you think 🙏

[AshtonStephens]

I partially second this - but I want more detail about Mitchell's proposal because it's too ambiguous to tell whether these are brain dumps or formal posts.

I will say - I'm not clear on the benefit of the 30 second daily effort for updates. That's more on an individual contributor side than the ecosystem organization effort that this post is leading to.

[jcnelson]

I will say - I'm not clear on the benefit of the 30 second daily effort for updates. That's more on an individual contributor side than the ecosystem organization effort that this post is leading to.

The reason I brought this up as an example is because it's an open-source project process that tries to meet some of the same goals this proposal articulates (raising visibility on the work we do, and holding each other accountable), but has proven to be inadequate because even though the overhead of doing so is small, it's still too big to be useful.

I strongly suspect that the primary reason that the WGs don't maintain a big online presence is because it's simply too much effort for largely-invisible gain. I personally have a hard time justifying spending time on anything besides furthering Nakamoto development, because spending working hours on other things gives me an unshakable anxiety that I'm making Nakamoto late by doing so. I'm hoping we can come up with something that gives @cuevasm what he needs while minimizing WG members' cognitive overhead.

[cuevasm]

There are two separate things here:

1. The WG you're referring to CHOSE to make that a requirement for its own purposes and that is a separate and additional expectation it introduced outside of WG standards. If you don't want/dislike the daily standup updates that WG has chosen to do, I would take it up with that WG lead but that is a completely separate thing from this global WG guidance. To make this even more clear, the only person this would change anything for from the Nakamoto group would be Will, who would be responsible for packaging the update. For everyone else that is not a lead, nothing changes.

2. There is no additional overhead for members, just for the leads to post regular updates. These are only expected every other week, nothing daily and as mentioned, guidance and support will be provided if anyone is struggling with a written update.

In my opinion, short updates about WG progress from leads on a regular basis is an ABSOLUTE MINIMUM expectation. We are not expecting eloquent blog posts or long written work, simply the minimum required to let the broader community know what's going on - it's quite informal and shouldn't take anyone longer than 10-15 minutes every couple weeks.

[AshtonStephens]

First, I love this post and how actionable it is. It makes a lot of sense to have mechanisms for better transparency.

I'm missing a few details that greatly impact my opinion about this proposal. To Judes point above about the amount of work and instead writing a "brain dump" for a post, it's unclear to me whether this proposal is suggesting regular brain dumps or wants high quality formal posts.

Individual Proposal Thoughts & Questions

1. All Working Groups need to fill in a complete brief and receive at least 15 ‘hearts’ on the Github discussion outlining what they intend to take on.

1. Where does the number 15 come from?
2. Who do we anticipate posting these hearts? Devs or leads or ICs or who?
3. What happens if there aren't enough hearts?
4. With what frequency will we be posting these brief proposals? Monthly?
5. Where are these going to be posted? GitHub? In separate discussions or all in one discussion that get continuously longer?
6. Can we get an example of the level of detail expected? Its hard to agree to standards of posting when the standards aren't explicit.

2. All WG leads commit to regular status updates posted on Github (details in the checklist).

1. How is this different from the first change? Is this a repost of the 15 hearted post?
2. Where do these posts live?
3. "Regular" at what frequency? Are these the Bi-Weekly ones?
4. Again, I'd love to see an example update so we know what the proposed standard is.

3. WGs commit to sharing a process by which new contributors can join, along with their requirements for doing so.

1. Where will this need to be posted? README?
2. What are the core requirements of a process to onboard? Is it a line of steps between "newbie" to "posting a PR" or is it a line of steps between "newbie" and "being included in meetings and discussions, etc.".

4. Working Groups commit to a meeting/communication schedule and to establishing a fitting communication channel for ongoing async collaboration.

1. I think it's fine to change this to expecting that working groups explicitly expect discord, since that's the current open source standard.
2. What would be an example communication schedule?

Summarized Thoughts

This document is missing some key details that make it hard agree to. Standards are always a balancing act of allowing ambiguity to meet individual's needs and being standard enough to enforce uniformly, and I think this proposal leans too heavily in the ambiguous direction. Some key places where details would be helpful:

1. The amount and the format of the information in these posts (A template for 1. and 2.)
2. The location of these posts
3. The expected communication channels.

Without these details these standards are anywhere within the range of "this really doesn't include enough information to be helpful" to "this is an overwhelming amount of work."

---

I'd rather have this in a document format than a GitHub post format. Maybe GitBook? I originally had a lot of questions about regular timelines and I had to read the followup to get the extra details. IMO these posts should be more self contained.

[AshtonStephens]

I just came back to this and I think my comments could be clearer. Here is what I think would be an improved section:

Original:

All Working Groups need to fill in a complete brief and receive at least 15 ‘hearts’ on the Github discussion outlining what they intend to take on.

• Why: A complete brief and a minimal level of community buy-in is a clear indicator the WG team is serious and will setup WGs for success.

What I'd find easier to agree to:

A week before the first community sprint planning of each month each working group should collaborate among themselves to write a brief work proposal in a provided GH discussion that includes the following:

1. Loosely what they're working on
2. How it helps the community or milestones
3. An estimated timeline of those tasks with explicit acknowledgement that they're not set in stone.

We expect ICs, Devs, and ecosystem stakeholders to approve these briefs before sprint planning incorporates them by measuring the number of hearts on each working group post against the median of the other working group posts.

• Why: Posting a brief about what the team is working on and how it helps the ecosystem will give broader context to the milestones we're working towards along with where that work is getting done.
• Why: Including a loose timeline will enable outside observers to know what working groups need more support as well as how long these updates are relevant. Additionally, including timeframes allows us to gauge the caliber of the work being done so that we know we aren't voting to approve a brief that will span multiple months under the impression it'll take a week.
• Why: Using hearts to measure agreement across briefs will ensure that the working groups never get out of alignment and we all agree on what steps take priority.

Again, I love the idea behind this but without clearer mechanisms and scope it's hard to give informed consent. And if we agree to do this then we need to make sure we really do this.

[cuevasm]

I think I'm open to getting more complex in the future, but I put this together with operational simplicity in mind. If a WG is taking on something that matters to community, it will not be difficult to get 15 upvotes and the info you've outlined here is already going to be featured as part of the brief they need to fill in. For us at the Stacks Foundation trying to support this, keeping it a simple matter of just being able to look there and not introduce a ton of new process is preferable and this is an easy upgrade from the current. I think if we run into new issues with that, we can adjust again.

I also think you guys are a bit conflating your experience with a very specific WG and subset of WGs on the tech side with that of WGs at-large. Many WGs are not technical, don't have a sprint structure, etc. etc. This updated guidance is a minimum level of expectations that work for everyone to enforce some standard communication at the global WG layer. I anticipate larger or more established WGs will continue to do more in certain areas as they see fit.

[cuevasm]

I'll answer all these questions, but I'll caution us from overengineering or overrotating on what is really just baseline communication expectations that we are trying to codify so we have some teeth when following up with folks that slip off of regular updates to the community. It doesn't need to be too complicated to get updates from leads on a regular basis.

Where does the number 15 come from?
This is a bare minimum of folks from a 40,000+ community that would indicate there is some level of need/interest/excitement for what the WG is proposing. Community buy-in is important, this is a very low barrier for folks that are part of the community and in tune with needs, it shouldn't be a barrier to work getting a WG started, but can be a barrier to opportunistic folks or spam/low-quality WG suggestions.

Who do we anticipate posting these hearts? Devs or leads or ICs or who?
Anyone from the community. The WG lead is responsible for writing up the brief and garnering support for it, much like they would a grant, resident application, etc. all right there on the Github thread where they post the brief.

What happens if there aren't enough hearts?
The WG does not move forward in an officially recognized capacity (included in index, etc.). We can't stop people from continuing to work if they want, but the WG wouldn't be part of the WG list or added to lead calls and support, etc. Getting enough hearts won't be a concern for any serious lead.

With what frequency will we be posting these brief proposals? Monthly?
This is answered. A brief is one-time. Updates frequency are all listed in the proposal: https://github.com/orgs/stacks-network/discussions/495#discussioncomment-7004779

Where are these going to be posted? GitHub? In separate discussions or all-in-one discussion that get continuously longer?
Github, covered in the same link above.

Can we get an example of the level of detail expected? Its hard to agree to standards of posting when the standards aren't explicit. WG leads will be provided templates and examples, it felt like a lot to include in this post.
You can reference any of the WG updates that are already out there. This isn't some dramatic new or difficult new thing, this is about the ability enforce some consistency. Eugenia generally does a great job with the brand one and could even see updates being shorter or simpler than what she provides: https://github.com/orgs/stacks-network/discussions/483#discussioncomment-6259915. I think it's hard to make explicit update expectations because my brand or marketing updates may look very different from tech ones. I generally trust leads to provide good updates and those that are struggling will be helped.

2. All WG leads commit to regular status updates posted on Github (details in the checklist). How is this different from the first change? Is this a repost of the 15 hearted post?
This is quite different. As noted, a brief is a one-time thing for WGs to describe what they are working on at the beginning. Updates are ongoing and go according to the frequency I laid out in the update schedule/breakdown.

Where do these posts live?
Again, Github right in the WG index. You can see how some WGs do that already, though somewhat infrequently: https://github.com/orgs/stacks-network/discussions/483. All we're asking for here is for people to be a bit more consistent with it.

"Regular" at what frequency? Are these the Bi-Weekly ones?
This is all covered in the cadence breakdown: https://github.com/orgs/stacks-network/discussions/495#discussioncomment-7004779

Again, I'd love to see an example update so we know what the proposed standard is.
_It's relatively impossible to enforce that every WG, especially working on such diverse things, can have a 'standard' update. This is why we are committing to helping people create these. It's really just a matter of helping people understand what work was done. The format I provided in the post above is fairly straightforward and likely works for most (what was accomplished, what is next, and what resources or support is needed going forward), but plenty of flexibility will be provided to leads. Example updates are all around the index. _

3. WGs commit to sharing a process by which new contributors can join, along with their requirements for doing so. Where will this need to be posted? README?
No, right in the brief that the WG opens on Github - that is why I have it under the 'brief section' in the breakdown and listed as 'one-time'. How people can join is a key part of any WG and that is why I have added that requirement to the brief. Many briefs now actually do include it (as you can see here: https://github.com/orgs/stacks-network/discussions/483#discussion-5088716), but now it would be required so we have some standards. This is about scaling - if no one knows how to join, WG growth will be limited.

What are the core requirements of a process to onboard? Is it a line of steps between "newbie" to "posting a PR" or is it a line of steps between "newbie" and "being included in meetings and discussions, etc.".
This is up to each WG to decide what makes sense for them. WGs can build the team they want, the only commitment is to being transparent about what they are looking for the and the process. If they want to get complex and have applications, great. If they want to openly welcome everyone, also fine. This is firmly up to the WG and its members and leads to decide based on what helps them accomplish their goals.

4. Working Groups commit to a meeting/communication schedule and to establishing a fitting communication channel for ongoing async collaboration. I think it's fine to change this to expecting that working groups explicitly expect discord, since that's the current open source standard. What would be an example communication schedule?

I don't really see this is as much of a "changed expectation". All WGs meet and communicate regularly for the most part, I'm just asking that they establish this early and make sure it's transparent so potential contributors know what they might be in for and help them determine fit. I'm also not going to provide a standard because I think every WG is so dramatically different that enforcing anything here doesn't make that much sense. Some WGs want to use Discord, great, love it. If others want to use Console or text each other, it's not really up to me and I don't think should be prescribed. I just think it's important that WGs are communicating regularly and they have the freedom to determine what this looks like, so long as they communicate back what it is. Again, the idea being that contributors have a sense of how the WG operates so they can determine if they are interested.

Summarized Thoughts
This document is missing some key details that make it hard agree to. Standards are always a balancing act of allowing ambiguity to meet individual's needs and being standard enough to enforce uniformly, and I think this proposal leans too heavily in the ambiguous direction. Some key places where details would be helpful:
The amount and the format of the information in these posts (A template for 1. and 2.)
The location of these posts
The expected communication channels.
Without these details these standards are anywhere within the range of "this really doesn't include enough information to be helpful" to "this is an overwhelming amount of work."

I appreciate all this, but I actually feel like the vast majority of these questions were answered with the breakdown of the update schedule I provided. I also noted further guidance and templates can/will be provided to leads, but I think we need to agree to the fundamental changes here before we fully build all that out. I also think it's important to work with each WG lead to find what works for them, so I'm trying not to be overly mechanical and strict here right at the start. This is a very minimal expectation in terms of communication from WGs and represents no more than 10-15 minutes of work every other week. On a quarterly basis, maybe 30-60 minutes to work with us on a deeper update if needed - pretty lightweight for running a whole WG in my opinion.

I'd rather have this in a document format than a GitHub post format. Maybe GitBook? I originally had a lot of questions about regular timelines and I had to read the followup to get the extra details. IMO these posts should be more self contained.

I think this is the exact problem I am solving. Right now, there is no one place you can go to see generally what's up in any given WG. This WG index, with the simple changes, can quickly become that. Imagine how useful it will be to land on the WG list and be able to know that a) all the WGs are active and real and b) by clicking on any one, you can find the latest progress update, which will have been from sometime in the past two weeks. I am not following how they aren't self-contained, the updates are directly attached to the ongoing thread for the specific WG which has the brief for it right at the top.

[jcnelson]

@AshtonStephens's detailed and thoughtful critique drives home an important point for me: the proposal, as written, creates a lot of cognitive overhead for WG leaders and members. It's not clear yet what an emerging WG standard will look like, and I'm not sure that it is currently a good use of time to go and hammer one out (given that Nakamoto and sBTC are looming deadlines).

To address this, what if the Stacks Foundation simply created a Google Survey with which to solicit updates from the WG leads every two weeks? Then, the Foundation can focus on creating a standardized representation of all of this information without having to spend lots of WG cycles on coming up with and adhering to a detailed standard. This information could be stored in e.g. an Excel sheet or DB somewhere, so if we want to change that representation later, we can do so without a lot of manual work. Thoughts?

[cuevasm]

This could be a way we operationalize this, however, I think you should consider the importance of visibility here. It's actually very beneficial for the broader public to come to the WG index (which we know STX holders do) and see a diversity of people posting and sharing progress vs. a single monolithic entity like say the SF in this case just posting for everyone. In this world, each WG has its own space, just like the brand one and others, and it makes it easy to find the latest update for that WG. As I noted, we'll compile these updates into in the various newsletters and channels we have, but I think the public record on Github, coming from the actual lead, is a far stronger signal and more useful and transparent than a Google Sheet that someone is unlikely to find.

I'll borrow from my response to Ashton above and the vision I tried to layout in the post: Imagine how useful it will be to land on the WG list and be able to know that a) all the WGs are active and real and b) by clicking on any one, you can find the latest progress update, which will have been from sometime in the past two weeks.

Further, I very much disagree this proposal creates any overhead for members. Members have no new responsibilities or expectations. It creates some very small overhead for leads, who, FWIW, are mostly already doing this or most of it, but are simply not doing it as consistently as needed. That's all I'm fixing here and I think it actually simplifies their life to know the expectations upfront and the support we'll provide is a new benefit, so again, super low overhead added (and I'm saying this as the lead of several WGs 😆). Really the fundamental idea with these changes is to communicate upfront that if you're starting a WG, it comes with certain (now more explicit) expectations. It's only fair to expect updates if they are agreed to upfront, so this update adds this detail upfront in the WG formation process so it's no surprise to any future lead.

I also agree a "WG standard" makes little to no sense in a decentralized, open-source ecosystem that has to account for widely varied 'types of work' and that's not what this is. This is a specific set of expectations for leads with regard to WG setup and communications. Frankly, I see it as table stakes for anyone trying to contribute or collaborate and don't see a way around such a minimal set of expectations for leads to 'share with the class'.

[cuevasm]

For those who don't have time to read through all the commentary above, I added some additional detail to the checklist in response to Jude and Ashton's input, mainly just emphasizing that the 'new time' commitment is fairly minimal and linking directly to example updates instead of vaguely referencing them. On a monthly basis, I don't anticipate these expectations to require more than roughly an hour of total work from WG leads. The visibility and consistency will be well worth the minimal effort, and as WG leads get spun up, they will have a lot of help :)

[cuevasm]

These expectations have been integrated into the 'Getting Started' information:

• 👉 Getting Started: What is a Working Group? #504
• 👉 Template: Working Group Intro Thread #503

Up now: Soliciting updated briefs from all WG leads and updating the 🟢 Working Group Index