[teampractices] [Wmfall] Roles and Processes for WMF Design
Federico Leva (Nemo)
nemowiki at gmail.com
Mon Feb 17 14:04:23 UTC 2014
Tomasz Finc, 09/10/2013 00:57:
> CC'ing team practices list for broad awareness
>
> And for those that are looking for other teams process/definition there
> is a nifty category that has all of it
>
> https://www.mediawiki.org/wiki/Category:Wikimedia_Foundation_teams_internals
Bump. I love seeing that category growing. :)
It seems that this discussion on documentation (process, collaboration,
communication etc.)... was not documented, despite being on/off for
months now. I've dropped something on wiki:
<https://www.mediawiki.org/wiki/Thread:Talk:Design/Design_process_and_documentation>.
Nemo
>
>
> On Tue, Oct 8, 2013 at 3:55 PM, Jared Zimmerman
> <jared.zimmerman at wikimedia.org <mailto:jared.zimmerman at wikimedia.org>>
> wrote:
>
> *Thomas*, looks great, I'll start
> https://www.mediawiki.org/wiki/Design/Team this week.
>
> *Arthur*, Yes, please work this out with your Primary designer
> specifically. In your case Kaity. The reason we're attempting to
> have all designers on the same schedule for Focus & Explore is so
> they can work and brainstorm together if they prefer.
>
> *
> *
> *
> *
> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation
> M : +1 415 609 4043 | : @JaredZimmerman
> <https://twitter.com/JaredZimmerman>
>
>
>
> On Tue, Oct 8, 2013 at 3:50 PM, Jared Zimmerman
> <jared.zimmerman at wikimedia.org
> <mailto:jared.zimmerman at wikimedia.org>> wrote:
>
> Yes, *Steven*, do you have a specific place you'd recommend it
> go on office wiki, I'd be happy to post it there. As far as the
> audience, the design group has many "clients" within the
> organization and I didn't want to accidentally omit any. As with
> any other thread that isn't relevant to you Gmail's mute feature
> <https://support.google.com/mail/answer/47787?hl=en> is great.
>
> Correct, *Arthur* while gmail excels in muting, it fails in
> search and replacing. Flare = secondary
>
> *
> *
> *
> *
> *Jared Zimmerman *\\Director of User Experience \\Wikimedia
> Foundation
> M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | :
> @JaredZimmerman <https://twitter.com/JaredZimmerman>
>
>
>
> On Tue, Oct 8, 2013 at 3:30 PM, Steven Walling
> <swalling at wikimedia.org <mailto:swalling at wikimedia.org>> wrote:
>
> Can we put this in a document somewhere, like Office Wiki,
> instead of via wmfall email?
>
> I am not sure this email was relevant to all 150 staff
> including HR, finance, and others who almost never work with
> designers.
>
>
> On Tue, Oct 8, 2013 at 3:14 PM, Jared Zimmerman
> <jared.zimmerman at wikimedia.org
> <mailto:jared.zimmerman at wikimedia.org>> wrote:
>
> Meetings are the mind killer. But collaboration can set
> us free.
>
>
> I've been thinking a lot lately about how Design works
> in tech, what works well and what is broken. How Design
> can use Agile methodologies to its advantage, and how
> the proliferation of meetings in agile can be a serious
> detriment to the creative process.
>
>
> I'm rolling out a few changes to the way Design will
> work with the teams and functional groups at the foundation.
>
>
>
> New Roles : Primaries & Secondaries
>
> Each focus area will be assigned a Primary and a
> Secondary from Design, these are the designers who will
> be your primary contact for a project or feature area.
>
>
> Primary— Invite the Primary to your standups and all
> meetings where design should have a presence. They will
> attempt to attend as many meetings that are relevant to
> design as possible. Invite Primaries to any project
> specific reviews and planning meetings, they will speak
> for design in these meeting. If they don't know the
> answer, they will find out. Primaries are responsible
> for working with PMs to define realistic schedules based
> on their own availability and that of the designers that
> will support them.
>
>
> Secondary— Secondaries support Primaries when it comes
> to making the work happen. While each group will have
> one official Flare, they may not be the only design
> support on a given feature. You should invite them to
> meetings where entire engineering teams are present.
> When a meeting needs to happen ASAP look to the Primary
> first, if they are not available the Secondary can
> represent design in their absence.
>
>
>
> Focus, Explore, and Collaborate
>
> Sometime designer work best when they are juggling 10
> projects at once, sometimes they work best when they can
> focus on a single task with no interruptions.
>
>
> Going forward the designers will block off one day of
> their calendar every week for Focus, and one for
> Explore. The remaining days will be for scheduled work
> and collaboration.
>
>
> Ideally we would have every designer have the same
> schedule for Explore, Focus, and Collaborate but this
> might not be possible due to individual and project team
> schedules. Designers will block out Focus and Explore on
> their calendars so externally it will be obvious which
> days are reserved.
>
>
> Focus
>
> In order to give their full attention to a design
> problem without having to context switch between
> meetings, Focus is a day without structured meetings.
> During Focus, designer may be in the office or they may
> be working from home, or a park, or a cafe, or in the
> office. Please do not schedule meetings with designers
> during Focus, or expect them to attend standups or other
> recurring meetings on this day.
>
>
> Explore
>
> During Explore designers can explore areas that they
> aren't assigned to, focus on projects that are important
> to them, and devote time researching new project that
> could shape the future of the Foundation and its
> projects. Please do not schedule meetings with designers
> during Explore, or expect them to attend standups or
> other recurring meetings on this day. Monthly the design
> team will host a 1 hour brown bag "Explore Wikimedia
> Design" that is open to the Foundation to attend, to
> showcase what designers have spent their Explore days
> focusing on as well as increase visibility for other
> projects that they are working on.
>
>
> Collaborate
>
> Mostly the same fun times you're used to, schedule
> meetings, write on whiteboards, have working sessions,
> etc. desk time doing design work.
>
>
> What does this mean to me as…
>
>
> an Engineer? You should still feel free to bring
> designers into your discussions and brainstorms,
> approach them with your projects, and questions. In lieu
> of scheduling meetings with designers on Explore days,
> simply walk over (or ping on IM) and see if they are
> available to talk.
>
>
> a Product Manager? When you're planning small meetings
> and projects make sure to invite your Spark, when
> planning larger meetings (quarterly kickoffs, roadmap
> planning) invite both your Primary and Flare,
> communicate project needs and timelines directly with
> your Spark.
>
>
> Everyone else? Come to Explore Wikimedia Design brownbag
> to get inspired, and understand what the Design team is
> working on.
>
>
>
> Feature Areas and Project
>
>
> Key:
>
> Design area
>
> Primary
>
> Secondary
>
>
> Analytics tools
>
> Pau
>
> Kaity
>
>
> Core Features
>
> May
>
> Brandon
>
>
> Growth
>
> Pau
>
> Vibha
>
>
> Language Eng.
>
> Pau
>
> Kaity
>
>
> Mobile
>
> Kaity
>
> Vibha
>
>
> Multimedia
>
> Vibha
>
> Pau
>
>
> Platform
>
> May
>
> Kaity
>
>
> Visual Editor
>
> Vibha
>
> Kaity
>
>
> Global Profiles
>
> Brandon
>
> Vibha
>
>
> Affiliations/Groups/Campaigns
>
> Brandon
>
> Kaity
>
>
>
>
> Questions & Answers
>
> Q: What if my team or project isn't mentioned?
>
> A: Try as I might I can't always be aware of every
> project that’s going at all times, if I've missed your
> project or feature please get in touch with me and I
> will make sure I do my best to make sure we provide
> design coverage for you.
>
>
>
> Q: How will you handle new designers being added to the
> team?
>
> A:As you can see above, even with the Design team
> growing many members are doing double duty as both
> Primary and Secondary on for multiple projects, as new
> designers are added to the team we will load balance as
> needed. Mostly likely new designers will join a project
> as a Secondary to get up to speed before being assigned
> to a new project or iteration of an existing one.
>
>
>
> Q: Does this mean I'll have the same designer(s) for the
> length of a projects?
>
> A: This is the goal, especially for the Spark, however
> as projects and resources change the Secondary assigned
> to a project may change if they are needed as a Primary
> on another Project, and vice versa.
>
>
>
> Q: What is the analogy between agile terms and Primaries
> and flares (for instance, is a Primary a scrummaster? a
> design tech lead? and a flare an engineer?)
>
> A: I had to do a lot of thinking about those roles and
> how they fit with design, if you mustdraw correlations
> between this framework and agile, the Primary is more
> like the Product Owner, In most teams both of those
> agile roles are already well covered and I'm not
> attempting to replace them. The Primary may also not be
> the one doing the most work on a feature area, but they
> are the main point of contact for other stakeholders.
>
>
>
> Q: Will Primaries sit with their teams?
>
> A: Maybe, this is up to the individual designers, I'm
> not going to mandate it, since each designer is a
> Primary for multiple teams (for now) it might end up
> with a lot of moving around day-to-day, also the
> designers like to sit next to each other so they can
> bounce ideas off each other.
>
>
>
> Q: What is the schedule?
>
> A: Designers have blocked out on their calendars
> Wednesday for Focus, and Friday for Explore, starting
> the week of 10/14
>
>
>
> Q: When is Explore Wikimedia Design?
>
> A: Monthly, dates TBD.
>
>
>
> Q: How will explore projects be built?
>
> A: In the case of Brandon and Pau, they may build their
> Explore projects themselves, in the case of the other
> designers, the monthly Explore Wikimedia Design brownbag
> share out will be a venue for developers to see things
> they are interested in building during their own
> time/20% time.
>
>
> All of the Explore work will be on-wiki both for
> feedback and for the community to be inspired by, We can
> work with Quim/Sumana to see if there is
> interest/availability in the community to build some of
> the explore features as well.
>
>
>
> Q: Is there a possible consensus/collaboration-driven
> way of handling designer/team assignments in the future?
>
> A: I can see this happening for future projects, but
> right now my focus is good coverage on projects that are
> already underway. I'm certainly open to individual
> designer mutually agreeing to swap roles for projects as
> well.
>
> Q: Will weekly design critiques go back to being design
> only? How will other teams hear about the decisions and
> discussion?
>
> A: Yes,Design reviews will be designers only going
> forward, they way they were originally, we've tended to
> post the feedback/notes, on a per project spaces, but we
> can also have a more general place to post these notes
> as well.
>
>
>
> Q: What if the days for collaborates for a team don't
> leave this flexibility in the schedule (no single match
> point)?
>
> A: This new schedule may alter the team velocity,
> however I think it will also increase quality and team
> happiness. Therefore it is in line with the tenant of
> "Do less, better
> <http://www.markramseymedia.com/2013/09/do-less-better/>" I'm
> ok with this. Are the other teams?
>
>
>
> Q: How do we determine how well this arrangement is
> working? or "What does success look like?"
>
> A: At its simplest level, success is a happier design
> team, where members feel like they can think further out
> in the future, and develop a creative vision with me for
> the future of our projects, they don't feel that now
> because much of our work is reactive to all the things
> that feel like they need to be done right now.
>
>
> The other major factors for success to me are a backlog
> full of designs that are interesting to foundation and
> community engineers. A clearer vision of the design
> roadmap. Elevation of the WMF as a place where great
> designer and designer flourish in an open (source)
> environment. A clear direction for where we want to be
> with design for the projects in 6 mo, a year, 3 years.
>
>
>
> Q: What does failure look like?
>
> A: Designer feel like they have too much work and spend
> explore doing assigned projects. Designers can't
> time-box themselves to focus on projects with the right
> balance. A lot of time is spent on Explore designs and
> no one in the community or foundation wants to build
> them. Explore projects don't feel like they form a
> cohesive vision for the future of design at WMF.
>
>
>
> Q: What is the role of Primary & Secondaries when
> interacting with the community?
>
> A: Both roles will be responsible for getting designs
> on-wiki, and responding to user and team comments
> on-wiki this is the current process and I believe it
> works well.
>
>
> Both roles will be in contact with their PM & CL to have
> the CL to do community research, and outreach. I don't
> see this part of the process changing much, I'm not
> aware of any issues with the current state of things in
> this regard, let me know if there are issues I'm unaware
> of.
>
> Any questions don't hesitate to contact me.
>
>
> *
> *
> *
> *
> *Jared Zimmerman * \\ Director of User Experience \\
> Wikimedia Foundation
> M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | :
> @JaredZimmerman <https://twitter.com/JaredZimmerman>
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall at lists.wikimedia.org
> <mailto:Wmfall at lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
>
>
> --
> Steven Walling,
> Product Manager
> https://wikimediafoundation.org/
>
> _______________________________________________
> Wmfall mailing list
> Wmfall at lists.wikimedia.org <mailto:Wmfall at lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall at lists.wikimedia.org <mailto:Wmfall at lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
More information about the teampractices
mailing list