Figma owner/maintainers
As we move from Sketch to Figma, we've discussed ownership over the UI Kit in various places. This issue is to come to a conclusion on who is able to publish changes and what that process looks like.
Some related comments from !1786 (merged) to help guide the conversation:
tauriedavis:
I think its okay for anyone to review a component. I don't think it needs to be a Figma Pilot designer or a Foundations designer. This also relates to later steps. We are currently saying the assignee will add the changes to Figma and publish them, but we want to follow the maintainer process where we have figma maintainers who publish changes.
For example, right now, assignees would not be able to publish changes because only pilot members have a seat. Ultimately, I think these people will start as Figma maintainers (if they are interested in that role) as they are well versed on how things are structured and maintained.
jareko:
I'm somewhat confused as to what we are the DRI's for. When I was in design management, if someone suggested a UX change or issue, they would ping me for a review or discussion since I was the DRI for design management. That feels like a natural flow, to assign a change or suggestion to the DRI for review and discussion. If we are not getting pinged on reviewing changes within Figma and/or Pajamas, if feels like we're not directly responsible for those things even though we are technically focused on them full time. I look at Foundations as stage work, so it would feel natural to have the same review process as if you were responsible for a specific stage.
Now, I know we are ALL responsible for contributing, but didn't we form this team to be DRI's for Figma and/or Pajamas? Can you provide some clarity around this? I guess I'm just not clear or understanding what we're directly responsible for. I feel that since this is what we're doing full-time, we need to look at this as our "stage", like other designers have stages and follow a similar DRI workflow.
tauriedavis:
For some background, @pedroms put together this document: https://docs.google.com/document/d/1HA68wEUxQDvX8hpkwQs3wfhSJwW1iiw7RHYwsAMtLYM/edit
This was created because becoming a design maintainer meant being responsible for too many things. There are different skill sets and we thought it would be helpful to allow for specialization in different areas. The idea is that it provides a way for designers to maintain aspects that they are interested in, without having to become an expert in everything. I also think the idea behind specific sketch/figma maintainers is that it would help provide some ownership over the document. My opinion of the Sketch file is that it got outdated, with incorrect specs in numerous places. Maintainers should help fix this problem, in theory.
I'm not opposed to Foundations being the maintainers, I think thats a natural evolution of the team anyway. But honestly, I'm somewhat new to Figma myself and I'd benefit from going through the trainee process so that someone who is more familiar with Figma can give me feedback and I can learn from them prior to publishing changes to the library myself. I have published changes to the kit already, but this was always after Jeremy has reviewed the additions. I'm perfectly happy to open a trainee issue for myself. My point being, even though I'm a UX Manager for Foundations doesn't mean I'm automatically at the level of a maintainer for something that is new to me.
Similar to other stages, when you merge in code, the maintainer is not the DRI for the work that happened. A maintainer is often not even in the same stage group, esp with the use of danger bot. The role of a maintainer is to provide feedback, a final check to make sure everything looks okay. Its not directly linked to being a DRI. Anyone in engineering can become a maintainer if thats something they are interested in doing — we've been working to adopt that same model.
Also, if someone was passionate about our UI kit and spent the time to learn it inside and out, I'm not sure it makes sense to block them from being a maintainer just because they aren't on the Foundation team.
Our job on Foundations is to provide guidance and help the greater department and organization. It's also to work on large, overarching initiatives that benefit the user experience. I agree that Foundations should be treated as any other stage, and the work we do milestone to milestone is what we are directly responsible for. For example, @jeldergl has become the DRI for color palettes. Not everyone may agree with all his choices, but as DRI, he is responsible for making the final decision.
These are just all my thoughts, based on conversations with others and what engineering does, but I'm certainly open to hearing from everyone else and changing opinions!