New Teams Board

[dave-mahler]

As a community member I want to see all active staff teams so that I can understand what is happening in the community and how to contribute.

As a staff member I want to see the status of each team so that I can join teams I'm interested in helping.

[dave-mahler]

@rapi-progcode check out the team board I put together. Now, the columns and labels can play different roles. Let me know what you think!

[dave-mahler]

I also added a few sample issues from the existing board and showed which columns they would be in in this new system.

[rapi-castillo]

Dave, I really like the new board. It feels more purpose driven. I think it can co-exist, no? With the new board as a higher level one and the old one as granular actions?

[dave-mahler]

I'd say ideally we only have the one board, though it may take a little more work. Maybe we should add some folks to this issue and see what they have to say. Ideally we can have some sort of proposal worked out by next week's meeting.

[dave-mahler]

@danodemo @rthbound @jpb5013

[rthbound]

I just looked over both boards.

@dave-mahler I see what you're saying here:

Now, the columns and labels can play different roles.

With the older board (B1), it does appear that the labels and the columns are duplicating function.

With B2 I have a clearer picture of the types of initiatives going on (colorful labels). I also have a much clearer picture as to the status of those initiatives. There are two columns that seem a little odd or out of place: "Quarterly Objectives"; "Recruiting/Planning".

For the first odd (to me) column, "Quarterly Objectives", may I suggest using Milestones like Q1, Q2, Q3, Q4? Or 2017Q1, 2017Q2, etc.

For Recruiting/Planning, that looks like it would fit well as a label. <--- I think maybe I am just misunderstanding the title of this column

Regarding current label usage, I'd suggest (but not strongly) ditching "In Progress", "Active", "Ready".

In Progress / Active can be represented in columns as suggested by @dave-mahler. "Ready" can be represented using other labels, like "design-help", "planning-help", "development-help", or something to indicate the type of help needed to move the ticket from Ready to In Progress.

[dave-mahler]

@rthbound thanks for the comments! For the Quarterly Objectives, I'm not really attached to that label. The basic idea is that, though there are teams focused on more near-term goals, we will want to, every 3 months or so, come together and decide on our high level priorities. This column is meant to keep track of those high level priorities, so we can all see how smaller actions are working towards that larger goal.

For Recruiting/Planning, the basic idea was that it is pre-proposal. That is, it's an idea that someone wants to work on, but hasn't gotten to the point where it would be brought up in a team meeting. Not sure what the right way to frame that is.

That's also a really interesting idea about using labels to keep track of the kind of help we're looking for. Then my question is, do we use labels or something else? I know we haven't made use of milestones. Could we repurpose those in some way?

[rthbound]

Milestones seem perfect for capturing those high level, long term objectives. Using milestones for tracking these gives a few benefits:

• Historical context
• Ability to push off an objective to a later milestone
• Multiple long term objectives (objective-A we want in 6 months / objective-B we want in 12 months)

I do now understand the Recruiting/Planning column. "Refining" might be a good alternative column name. I digress. :)

Regarding the use of labels. I think having multiple purposes for labels is okay. Check the labels dropdown menu on the rails project's issues page. The problem with B1 was that some labels were merely reiterating the column names.

In general, I think that B2 is a leap in the right direction. With B2, we can better utilize the filters on this project's issues page.

That's all I've got!

[PamelaJohn]

@rapi-castillo should this be a Pilot, rather than a Function? My understanding of Functions is that they have been proposed to the community, voted on by the community and ratified by the community once they were approved. I do see the notation that this issue was created based on a "proposal" which "needs to be ratified" but there are important steps between "proposal" and "ratification" which appear are being skipped. Specifically, community discussion and community vote in #operations.

I would encourage all of us to be mindful of the processes currently in place and aware that any proposals to change existing processes should follow both the existing Community Guidelines and Change Processes which were put into place by ratification of ProgCode community vote. @jpb5013 and the Operations Team have been strategizing and putting plans in motion once they have community buy-in through open community discussions in #operations. At minimum, it seems to me that Joe should be consulted to make sure that this does not conflict with work already being done, given that would disempower that team and those members working to implement ratified strategies.

To be clear, the above statements are not intended to quash this idea, but to ensure that it is lifted up through proper decision making processes--otherwise, it could be challenged as being in violation of existing Guidelines. Would welcome further discussion here and/or in #operations. Thank you!

@dave-mahler @rthbound

[rthbound]

@WoobieTuesday it seems this issue is just proposing a new view of existing issues that better leverages Github's features and filters.

I see it not as a change, but as a contribution from a member. My feedback is just confirming that the board (project) @dave-mahler has contributed is more informative to me. My feedback also suggests using a feature Github provides, Milestones, so we can provide additional insights about when, roughly, we hope to resolve or complete an objective.

/cc @jpb5013

[stephenscapelliti]

Maybe I'm missing something, but this appears to restructure our organizational layout in GitHub. To what does "Quarterly Objectives" pertain? Are these objectives of projects, involving App Partners? Are they objectives involving Network Partners? What are the criteria we will use to set objectives and to evaluate whether the objectives are being met?

[dave-mahler]

@WoobieTuesday this is as close to the pilot initiatives as I could make it. This was never intended to act as a Function (yet). I created the new project because it was the best way to show the changes I was proposing.

[dave-mahler]

@desmondjones here are the 3 things you listed in #discussion:

1. I'm not understanding the purpose of the proposed change.
2. It wasn't brought up in the community, but it requests what appears to be a fundamental change in the organization of the GitHub.
3. The change appears to have a learning curve that could affect what we're doing with members, projects, and network partners.

And my responses:

1. The fundamental purpose of the proposed change is to organize issues based on their phase of development, rather than by their group (ex. Partner Outreach) and that we (continue to) use labels to mark what teams are affected by an issue. The current system is redundant and also makes it very hard to understand at what phase of development each issue is.
2. Yeah, I thought I had brought it up, but I may have just tagged a few people in the thread itself. The intention was never to hide this from public view/discussion, it just fell off my radar.
3. Yes, it would require some adjustment, but I believe that it will be worth it, as this structure for columns is actually much more similar to the way coders use boards (i.e. columns are used to show phase of development). I also think this will help us keep track of proposals better, as we can see what phase they are (from ideation-->proposal-->ratification)

[dave-mahler]

As for Quarterly Objectives, every 3 months or so we have a strategy meeting (ex. Winter Strategy meeting) and one purpose of that meeting is to set high level objectives. Those high level objectives are very useful to display on the same board as our current initiatives, so that we can make sure our sub-team goals are in alignment with our high level objectives.

[rapicastillo]

Here's my take on this! And awesome to see so much activity here.

Who are the boards for?

I think the board that Dave did is great to have everyone in an intentional perspective on where or what is happening in terms of the overarching goal of each function. The user stories that @jpb5013 and @dave-mahler worked on I think reflects here. I think this is a pilot, as with any, which is great! Because we want folks to keep on starting things, :)

The functions doc we have atm – the one we present in onboarding – provides an eagles eye view on what the teams are working on atm. It is itself a pilot! We are not married to it, but it is the one that I am currently pushing, as dave is currently pushing the board.

I don't see why it shouldn't both exist as they serve very different purpose. As I've said, folks will engage however they want to engage, and if the awesome board Dave made connects with people, then we have more people onboard, and if more people find more value on how the current pilots board is setup, the better!

What this presents

I think this presents a great insight on when we can trigger the change process, and consequently when we can trigger the need for decision making, so I encourage us all to really add in to the decision making use cases here: https://docs.google.com/spreadsheets/d/1IiyLVJNz3ouDx9D7JKnP-1pTteeEyyJYlXb9RtS8mNo/edit#gid=0

[stephenscapelliti]

The fundamental purpose of the proposed change is to organize issues based on their phase of development, rather than by their group (ex. Partner Outreach) and that we (continue to) use labels to mark what teams are affected by an issue. The current system is redundant and also makes it very hard to understand at what phase of development each issue is.

Thank you for the explanation. So here are my questions:

1. What issues are being proposed for organizing? To what do they pertain?
2. Does this pertain to members' projects in the channels?
3. Does "teams" pertain to ProgCode organizational structure (e.g., Onboarding, Outreach, etc.), or projects (e.g., Swimmy, National Voter File, etc.), or both? Or something else?
4. What is redundant? I'm not sure what has been duplicated or repeated.
5. How is "phase of development" defined? I ask because I am unaware that we currently track phases and how.

[rthbound]

@desmondjones, speaking only to the redundancy (item 4)

The labels themselves achieve the goal quite well, and the buckets titled the same as the labels are the redundancy. I've included screenshots to help see what I'm seeing.

[rapicastillo]

@dave-mahler and I have talked at length about it @rthbound and the result of whic is that the label presents a good link to all the list of filtered once, and the column title provides a good columnar presentation. It's redundant, yes, but serves different purpose. The main goal of the current functions solution is to repurpose Github in a way that will be able to be digestible to new people.

[rapicastillo]

We could have these compressed to different hubs, we can also be more streamlined, but at the moment it does present a redundancy but it is for this purpose that it was repurposed.

[rapicastillo]

And what he's doing is much more purpose driven and is directed mainly towards staff members.

[PamelaJohn]

From "Non-Hierarchy" on Page 8 of the Staff Handbook ratified Mon. January 30, 2017:

“Power” is posed not as an entity that is entitled to anyone – despite being a staff member (see Ego Check below) – and is not the currency we want to cultivate. Influence for the good of the community, good will, and personal relationship, are the entities we try to cultivate in the community – a non-hierarchical ecosystem allows for that to happen.

From "Non-Hierarchy" on Page 9 of the Staff Handbook ratified Mon. January 30, 2017:

Contrary to a top-down approach, we encourage people to not wait for any permissions and give themselves the permission to do things they want to do. This is rooted in the idea and belief that people within the network wants what is best to serve and add value to the community, so the trust everyone gives out to everyone will hopefully affect the decisions of the individuals within the network.

However, it is also a network of humility and a lack of ego, wherein we should be able to pull back folks on the things they do, without ruining their spirit. All staffers are encouraged to pull back when needed, and are also encouraged to push forward any time.

From "Ideation" on Page 12 of the Staff Handbook ratified Mon. January 30, 2017:

Because of this chaos or constant collaborative energy in the community, we have to be able to open to any forms of ideas, and quelling ideas – shooting ideas down – is the most unproductive thing a staffer can possibly do. We will do everything we can to encourage conversations about ideas, and anything that is counterproductive to that will be grounds for a campaign for a staffer to be removed.

@rthbound, while it may seem to you or to others that I am a staff member "shooting down" @dave-mahler's awesome idea, it's not the case. I think the idea itself is great! But Dave is also a staff member and I am concerned that the process by which his idea is being presented and lifted may not be transparent enough, may not follow the steps set out in "Change Process", and may not have previously consulted the teams which will be impacted if the change is instituted.

If a staff member's great idea is lifted to a vote without following procedures the community previously voted/ratified should govern the presentation of ideas which change internal processes, the result is the staff member effectively ends up "shooting down ideas" that the community (some non-staff members) have already voted on. The result is the exercise of hierarchy. In essence, as I read the Staff Handbook, it is the duty of staff members to make sure that the historical votes of the community are respected and not changed without following procedures which are in place to prevent staff overreach.

I may be wrong about all of those concerns. That is why I started by asking here for clarification.

[stephenscapelliti]

I love that our Staff Handbook encourages independent action. We do that with respect to the projects of our members, leaving them to decide the best approach for the things that they bring to the table. Initiation of action for oneself, to be a more productive participant, fits the definition of "independence". Where the action will affect the work of others, it ceases to be independent, as it requires that others change what they do. I think that's the difference here. I'm fine with the structure of the GitHub, particularly because I've managed to learn it (to an extent) and as I'm working through my learning curve and becoming more productive in the functions I have to perform in ProgCode.

That said, I'm open to change, particularly if it will serve the greater good. That is why I've asked the 5 questions in my comment above.

[dave-mahler]

@desmondjones responding to your questions:

1. What issues are being proposed for organizing? To what do they pertain? I'm proposing this apply to all issues on the "functions" board, not the "projects" board
2. Does this pertain to members' projects in the channels? Nope. This is still for internal Operations issues
3. Does "teams" pertain to ProgCode organizational structure (e.g., Onboarding, Outreach, etc.), or projects (e.g., Swimmy, National Voter File, etc.), or both? Or something else? The former. Though I think one nice thing about labels is that we can assign multiple labels. Considering many issues have multiple stakeholders, putting each issue under one column may not be representing a full picture of that issue. On the other hand, an issue can only be at one phase of development. Thus, I think columns are a better way to indicate status, while labels are better for identifying stakeholders.
4. What is redundant? I'm not sure what has been duplicated or repeated. rthbound already answered this in his comment above.
5. How is "phase of development" defined? I ask because I am unaware that we currently track phases and how. Well, I think we're moving in the direction of having things be in different phases. for instance, there's now pre-consent and post-consent. I imagine there will be a few more phases as we continue to flesh out the change process.

[dave-mahler]

Meeting notes from today's call: https://docs.google.com/document/d/1gSsgD5UTpcxsnbnc16XLFW9sJOcXAJFzCufKGUVLyrc/edit

And video of the call: https://progcode.slack.com/files/joepbreslin/F4KLHANBU/zoom_0.mp4

[jpb5013]

Great chat yesterday! Apologies I missed all of this great conversation previously, excited to see how we can continue to evolve our operations. To address a few comments from the thread:

• Pamela - Regarding "functions," the overall ProgCode structure should be Functions, Sub-functions, processes performed. So, GitHub/Airtable are tools used to execute against defined processes for all functions. Right now we're all little all over the place with our "functional" names, it'll be something to better specify as things continue to evolve. Just overall I wouldn't think of this as a Function, rather something that enables functions to, well, function
• Rapi mentioned the ProgCode Stories, which is one thing that made me excited about Dave's proposal. Specifically, the milestones can lump up a number of issues into more discernable actions as they relate to quarterly objectives based on our strategic priorites

On Thu, Mar 16, 2017 at 10:40 PM, dave-mahler notifications@github.com wrote:

Meeting notes from today's call: https://docs.google.com/ document/d/1jzzM0yorI3FcDa_0OAetQDpUXTbWTYRVUCd7vhzVuaI/edit?usp=sharing

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProgressiveCoders/functions/issues/64#issuecomment-287213240, or mute the thread https://github.com/notifications/unsubscribe-auth/ALZmqyG-dOTLj0K0CrfDM2sDpTdDDZeEks5rmbp5gaJpZM4L--uy .