Update workflow.md for "community projects"

[aprilmj]

Added a bit about community projects (formerly called "upstream", language improved by Erik).

Please check my description and edit as needed - I'm not positive that I completely understood the different types of community work, and don't want to use misleading language.

This should close issue #820

[choldgraf]

Thanks for this - a quick thought on the details here:

My understanding is that the process for community initiatives is a bit different from our other initiatives, in that community initiatives define their task list in a separate issue or project board that we cross-reference from our "community initiative" issue. Do others agree that is missing from this description?

[choldgraf]

Something else I'm noticing as I look at the initiatives board, where we've now got several community projects:

1. It's not clear how those projects relate to the columns ("needs refinement" etc). Should we just assume that they perpetually stay in the "needs refinement" column, with the idea that each one will generate more specific/actionable initiatives that we then track independently on the board?
2. Many of those projects have metadata embedded in their titles (specifically "PROJECT" and dates), which makes it hard to parse them. Could we instead add start date and end date fields to these boards, and use a "community initiative" field to categorize them? The dates could be something specific like the "period of performance" for contracts, or could be something team-driven like a time box for when we want to conclude an initiative.

For an example of 2, see this screenshot:

And this is the kind of structure I'm proposing (old version above and below, new version in between):

[aprilmj]

1. It's not clear how those projects relate to the columns ("needs refinement" etc). Should we just assume that they perpetually stay in the "needs refinement" column, with the idea that each one will generate more specific/actionable initiatives that we then track independently on the board?

That seems like a good place to start, based on what @jmunroe described in his Pythia thought experiment. We may realize we don't want to keep the long list in "needs refinement" once we're sure we have them all covered.

2. Many of those projects have metadata embedded in their titles (specifically "PROJECT" and dates), which makes it hard to parse them. Could we instead add `start date` and `end date` fields to these boards, and use a "community initiative" field to categorize them? The dates could be something specific like the "period of performance" for contracts, or could be something team-driven like a time box for when we want to conclude an initiative.

+1, that sounds like a great idea. I like that we're figuring out details as we go.

[choldgraf]

Are there any objections to using board metadata for that information? In particular if @jmunroe or @colliand may have thoughts since (I think) they are the ones that chose that format for the PROJECT issues.

[jmunroe]

I think shorter issue names and the use of labels/tags to store start and end dates makes sense. I've made those changes to the names.

[jmunroe]

I merged in Chris reformatting suggestion.

[jmunroe]

I think there is more to discuss about 'community projects' and how to integrate them into our on going work in defining initiatives. But there is nothing blocking merging in this PR since it already makes it clear that this this a work in progress.

@aprilmj I think you can click the 'Merge pull request' when you are ready to do so.

[aprilmj]

Thanks everyone! For future reference, what's this team's norm for documentation-related merges?

I was just thinking that I would be 100% ok with @jmunroe pushing the button while you were looking 👍

[choldgraf]

We don't have a formal policy for merging documentation changes, but I think that following the team's decision making principles around bias towards action, I'd be comfortable encouraging people to "merge first if they think it's safe to try" unless there's something controversial or potentially wrong in there...