Our project management board has a new look

[kelenelee]

@allthatyazz tasked me with creating templates for the FF usability study. I also proposed that we take this opportunity to declutter our board in general. More details behind these choices are in #395.

Requesting feedback from @allthatyazz @cunninghamej @navarroliuanthony @winoue90 @sandraberjan @hdchangie @tamalatrinh. I know we typically use Slack to discuss, but since Slack auto-deletes messages after a few weeks, I think it's important that we start keeping our dialogue where it won't get lost to the ether.

Update 5/2: instead of creating way too much whiplash from direct experimentation, I've moved my tinkering to one of our Figma files. I'm also going to explore Github's forking functionality, to see if I can try to make changes that way.

Columns

• created new project board just for onboarding
• closed depreciated or redundant issues
• deleted "Ice Box," "New Issue Approval," and "Onboarding" columns as a result of these columns being basically emptied
  • new issues go into "Add cards" panel now, next to the "Filter cards" search
• moved "Ice Box" issues to "Backlog"

Labels

• deleted unused labels or inappropriate labels
  • replaced feature: _ labels with milestones, if the label made more sense as a goal to be tracked with a progress bar
  • replaced p-feature: _ with just feature: _ as a result of most of the original feature: _ labels getting deleted
• changed most label colors to be light, not bright, to minimize distraction from issue names
• number of colors have been reduced
  • role: _ are all light green
  • feature: _ are all light blue
  • epics and dependency issues are all bright yellow
  • documentation related issues are all light purple
• label names are now consistently lowercase with a colon

Milestones

• deleted empty milestones
• moved "Guide" and "Usability Testing" milestone issues under "Figma Foundations"

Onboarding issues

The 3 issues have been combined into 1 issue. The template for the issue can be submitted with the click of one button.

[navarroliuanthony]

I think it looks great! Everything is much more intuitive and less overwhelming for sure. My suggestion is just to perhaps add templates for the first issues people create during onboarding and put them in the "Start Here" column on the onboarding board. This way, people don't have to dig through issues in the "Done" column to find their templates. Not a lot of feedback to give, to be honest. It looks really good. Thanks for your hard work, @kelenelee!

[kelenelee]

@navarroliuanthony thank you for sharing your feedback! The onboarding project board's "Start Here" column has a link that creates the first issue for them. (There used to be 3 issues, but i've combined them into one so that newcomers don't have to do this more than once.)

That one link definitely doesn't stand out visually as much as a real issue used to. I may have to figure out a way to draw people's eyes more. Maybe adding emojis to the column titles will help.

You have a point, though, that people's eyes may be drawn to issues in the "Done" column, and possibly be confused. I will have to look into that. Thanks again :)

[hdchangie]

Thanks, @kelenelee , for the hard work! Now the kanban board looks so much easier to follow and hopefully it will create less confusion for newcomers.

Just echo what Anthony has mentioned, it's a good idea to put all the "templates" in a designated location on the board. The other day I was a bit frustrated due to not being able to find where the templates were and had to use the "search" function instead.

[kelenelee]

@hdchangie thank you so much for your feedback! Yes, I agree that the researcher issue templates aren't findable right now. I've been rethinking the whole concept of issues as templates. It's likely that, for now, all templates will be moved into the default issue templates page. (Not 100% happy with this as a long term solution tbh, but that's a whole other discussion)

[allthatyazz]

Hi @navarroliuanthony and @hdchangie , thanks for taking the time to review and add your comments!

About the onboarding templates, let me provide more context: please forget about what we used to have in the past as several issues for onboarding tickets.

Kelene actually merged all the templates into a single issue. The first thing that the user is going to face is the Start Here column and the user can access the template with a single click.

I believe the previous format was confusing. I witnessed a low compliance rate among our new joiners. Once the joiners do the first ticket, there is very little motivation to complete the 2nd or 3rd ones. But the new hypothesis is that once the user starts the process, they would be more invested to complete the rest of the tasks. It might turn out wrong but we can dog food it within our team to see :)

Also now we have a very smart way of using templates. Once you click on the New Issue button you can instantly access the templates specific to our team's initiative.

[allthatyazz]

Oh yeah, I see that Dongchen refers to interview templates.

[kelenelee]

and I just realized that anthony was talking about onboarding! oops. I'm not awake yet :)

[allthatyazz]

My suggestion is just to perhaps add templates for the first issues people create during onboarding and put them in the "Start Here" column on the onboarding board. This way, people don't have to dig through issues in the "Done" column to find their templates.

yes.

[allthatyazz]

We can address Dongchen's concern, by adding the interview templates to the GitHub templates folder which was your plan anyway.

[kelenelee]

I witnessed a low compliance rate among our new joiners.

I would LOVE to know more about your observations 😃 maybe next we catch up?

[sandraberjan]

@kelenelee Thank you for taking on this large task. My general feedback is that your changes are adding significantly more clarity. I will share more specific thoughts in another comment.

[sandraberjan]

Observations and suggestions based on my own onboarding experience Part 1

A. Structural Flaws
The biggest problem with the onboarding experience is having to learn more than one thing at the same time:

1. How to use Github (in general if the user is new to it, how WE use it specifically)
2. Design Systems (what they are, what we do, what our goal is)

The content of my first issue was to read about design systems. But the immediate success of completing the issue depended on whether I had figured out how to use GitHub. There were actually TWO learning goals in the issue: reading about design systems was the explicit one, but being able to use GitHub at even a basic level was an implicit, hidden goal.
More on GitHub: I was somewhat familiar with Github prior to onboarding. Despite that, I had a very difficult time wrapping my mind around the workflow. I figured things out with a lot of trial and error. I learned to use Github by practicing and doing, not reading about it.
-> Learning to use GitHub could
-be separate from learning about Design Systems
-involve guided practicing/doing not just reading
-come before learning about Design Systems
-be clarified as a prerequisite to further work

@kelenelee I think your idea of a GitHub tutorial plus emphasis on the importance of documentation fixes this problem.

[sandraberjan]

@kelenelee pointed out that learning to use Typescript is a key part of onboarding. My experience: I figured out how to use it by playing around with comments such as this one, and then clicking "Preview" to see how it looked. Only after I did that a few times did I look at guides on how to use typescript. I wonder if trial and error is as key to how others learn during onboarding, and if yes: maybe we can incorporate it into a tutorial.

[sandraberjan]

Brief conversation on slack with @kelenelee helped me understand our problems better: "We are trying to use Github like Jira, but some of the most fundamental aspects of Jira are completely nerfed. Nesting issues, and automating the tracking of time."

[sandraberjan]

I will hold off on providing further feedback re. onboarding until my meeting with @kelenelee on 04/26 so I can understand the dimensions of the problem better.

[sandraberjan]

Observations and suggestions based on my own onboarding experience Part 2

B. What is the purpose?
Watching Jennie Yip's talk and reading Khalmatova's chapter -> informative BUT the link back to our work is not explicit and clear
Wataru seems to have provided the missing link in Issue #412
"Wataru summarized the course of the DS project as going from “throwing assets” at teams to “building the skeleton” of the DS, because some teams weren’t ready to start incorporating components into their work. His explanation helped me understand the project better" https://docs.google.com/document/d/1ccWBKkVl0pd_Y0DJvEUx4DLT1HZJjVnylf_z6zMvMpU/edit

[sandraberjan]

After watching Jennie Yip's talk and reading Khalmatova's chapter, new volunteers have to add their key learnings to the discussions. Is this useful to help them understand the ideas? No real discussion takes place.
We can read others' responses but there's no quality control; what if some of the responses have a mistake or did not grasp the concept correctly?
Bottom line: what is the purpose of the discussion? Is it fulfilling that purpose?

[kelenelee]

No real discussion takes place. We can read others' responses but there's no quality control; what if some of the responses have a mistake or did not grasp the concept correctly? Bottom line: what is the purpose of the discussion?

BRILLIANT @sandraberjan this is also why I made this poll (you can vote on it btw).

[kelenelee]

4/21, Yas connected Sandra and me
Slack thread

Yas: Sandra! Two weeks ago we talked about your onboarding experience and your interest to improve the process and the copy of first issues. Well Kelene has started that initiative along some other major changes to our project board.

Sandra: Kelene, from my first glance, it looks amazing what you are doing with the reorganization. I’m excited to take a closer look and add to the discussion on Github. Sandra, you can find more information through issue #395 and the discussion forum.
Kelene! the nice thing about having Sandra test the onboarding follow is that she just went through the previous tickets and she can compare both experiences (edited)

Yas: Awesome! There are some areas that I wonder if it is worth more explorations like if the fewer pages on the Wiki is better or worse ... Or combining all the templates into one is logical or not... Another example is the new FF templates. the goal behind using the templates should be saving time and not thinking too much so I am not sure if combining the plan, analysis and conduct are necessarily a good thing if the user has to delete some stuff every time ...

Kelene: I agree that combining all the templates together is imperfect. The reason why I did it this way is because once there are a lot of issue templates, it gets really hard to sift through. If there was an option to create headings, this would be a different story. We don’t have a lot of templates right now, but I was worried about the length of our templates page over the long term

I added a Backlog card with a link to the issue templates page.

As for the wiki – the reason I got rid of a lot of pages is because of the “Pages” dropdown. It auto-populates every page, in alphabetical order, and will not display more than 15 pages at a time. There used to be 37 pages, some of them blank, in an order that didn’t make informational sense. “Pages” is there no matter what – therefore someone might use it – therefore we have to design for it

What’s currently impacted negatively by the condensing of pages is the History section of the background page. But, my opinion is that the long length issue is caused by the section being written poorly. Once the writing is cleaned up, it should be more readable, and any extra info can start going in the appendix

Also, learning Markdown is necessary to know how to edit the wiki – another obstacle for newbies…

Yas: Also, the roadmap diagram does not mean anything really - with the exception of some older members ( Nas and Jeanette) I have never seen a new joiner say "Aha what a great product roadmap - I see exactly what is going on in this project" ... In every project, many things can be related. I am not sure why our team ended up with such a crazy road map.
It would have been much better if different initiatives had been mentioned seprately.
Just another thing before I go to bed, Kelene! you are doing amazing--- I do not believe that I would ever have the courage to make all these drastic changes to the project myself- but I feel more empowered thanks to you

Kelene: Awww thank you so much Yas. I would have said the same about you – I did not have the courage to do this until we had our 1-on-1!

Sandra: Hi Kelene, I just responded to your Calendly and scheduled a chat. I am going to share more specific thoughts in the issue discussion since it will be more useful to have it there. You are working at lightning speed and I am so impressed, btw! I’m working on a breakdown of the structural problems I encountered during my onboarding and sifting through them depending on whether your changes fixed it or if it is a deeper problem.

I am dealing with a bit of cognitive overload. It’s challenging to keep up with the changes. I think that’s interesting in itself. Here’s why I think it’s happening: I onboarded and started using both Github AND Figma for the first time. I also had not been familiar with design systems prior to joining the DS team. That’s three complex ecosystems all of which require either big picture thinking or learning to work within an entirely new context.

Your changes are very clearly a huge improvement but they are occurring at a stage where I was just getting a bit familiar with our github board so it feels a bit like a very exciting and pleasant avalanche. I point this out not because it’s been painful or anything like that but because I think it it gives us some interesting info on why people new to the DS team who don’t know GitHub are so lost: two new large complexities.
2:35
I wasn’t sure where the following would fit best in the issues so I’ll share my thoughts here for now.
A. Structural Flaws
The biggest problem with the onboarding experience is having to learn more than one thing at the same time:

1. How to use Github (in general if the user is new to it, how WE use it specifically)
2. Design Systems (what they are, what we do, what our goal is)
   The content of my first issue was to read about design systems. But the immediate success of completing the issue depended on whether I had figured out how to use GitHub. There were actually TWO learning goals in the issue: reading about design systems was the explicit one, but being able to use GitHub at even a basic level was an implicit, hidden goal.
   More on GitHub: I was somewhat familiar with Github prior to onboarding. Despite that, I had a very difficult time wrapping my mind around the workflow. I figured things out with a lot of trial and error. I learned to use Github by practicing and doing, not reading about it.
   -> Learning to use GitHub should
   -be separate from learning about Design Systems
   -involve guided practicing/doing not just reading
   -come before learning about Design Systems
   -be clarified as a prerequisite to further work

Ok I just read your new Wiki and you address most of the problems I pointed out.

Kelene: I don't know how familiar you are with Jira. We are trying to use Github like Jira, but some of the most fundamental aspects of Jira are completely nerfed. Nesting issues, and the tracking of time. Jira is a popular software as a service that companies use to document work. I am no expert by any means. But from my understanding, issues make up stories, which make up epics, which make up initiatives. This system of Agile/Scrum is meant to be used by engineers, who estimate how many points a story needs. Then the story gets planned into sprints (2 week cycles).

If github is sort of like Jira but also isn't, we're not engineers, we have no sprint cycle, and we're stuck using this thing… how do we make it make sense? How do we enable volunteers to stay and nurture their discipline?

Sandra: So we are essentially using a workflow system not made for us with the wrong tools.

[allthatyazz]

A side note: I came across a podcast episode by P.J Onori, Pinterest Design System product lead, talking about how their team use Jira https://anchor.fm/designsystemofficehours/episodes/Ep-7-JIRA-MORMONT-e1h5o74