Skip to content

Web UI (GUI) Squad

Jump to bottom
Dixsie Wolmers edited this page Oct 26, 2021 · 14 revisions

Social Contract

General Team

  1. We work in two week increments and daily stand up will be run by team member volunteers - Sprint Schedule

    Sprint number Start Date End Date Daily standup lead
    2021-01 12/30/20 01/12/21 Derick
    2021-02 01/13/21 01/26/21 TBD
    2021-03 01/27/21 02/09/21 Nicole
    2021-04 02/10/21 02/23/21 Yoshie
    2021-05 02/24/21 03/09/21 Dixsie
    2021-06 03/10/21 03/23/21 Derick
    2021-07 03/24/21 04/06/21 TBD
    2021-08 04/07/21 04/20/21 Pari
    2021-09 04/21/21 05/04/21 Sukanya
    2021-10 05/05/21 05/18/21 Derick
    2021-11 05/19/21 06/01/21 Nicole
    2021-12 06/02/21 06/15/21 TBD
    2021-13 06/16/21 06/29/21 TBD
    2021-14 06/30/21 07/13/21 TBD
    2021-15 07/14/21 07/27/21 Dixsie
    2021-16 07/28/21 08/10/21 TBD
    2021-17 08/11/21 08/24/21 TBD
    2021-18 08/25/21 09/07/21 TBD
    2021-19 09/08/21 09/21/21 TBD
    2021-20 09/22/21 10/05/21 TBD
    2021-21 10/06/21 10/19/21 TBD
    2021-22 10/20/21 11/02/21 TBD
    2021-23 11/03/21 11/16/21 TBD
    2021-24 11/17/21 11/30/21 TBD
    2021-25 12/01/21 12/14/21 TBD
    2021-26 12/15/21 12/28/21 TBD

  2. Increment planning will occur every other Monday from 8:30 AM - 10:30 AM Central (7:00 PM IST), two days before the increment end.

  3. We agree to have a design team playback every week to reach alignment and create transparency in the work being completed.

  4. We agree to use open Slack channels that contain more team members when discussing or asking questions about the Web UI to provide transparency into the Web UI work to the broader team

    • Post new story kick-off announcements
    • Post any topic that would be relevant to the larger team
    • Limit use of the squad's private slack channel to design team only focused conversations

  5. We agree to use GitHub as the primary source of truth whenever possible to minimize where a team member must look to find pertinent information about a Web UI feature

    • Internal conversation in Slack channels will be added with a short description and a link to the thread
    • Intellectual property or proprietary information will be added to a Box note, which we will provide a link to in the GitHub story, along with a short description
    • Stories need to have enough information for anyone to understand the problem being solved, references to how the solution was determined and any dependencies

Designers

  1. No visual - No meeting

    • We agree to use a visual to test with users or we don't schedule the session
    • We agree to have an ugly wire or visual to easily convey complex problems or solutions

  2. The primary way to communicate design changes with the community is through the email list and discord channel. Any information that is relevant to the feature should be added to the GitHub story.

Front-end Developers (FEDs)

  1. We agree to dedicate time daily to the code review needs of our agile squad, as well as to the community, in order to keep the code fresh and minimize merge conflicts that bottle-neck the development process.

  2. We agree to discuss code review needs in daily standup to determine who will own the code review for specific stories. The story/review owner will add the code review owners to the code review list and the remaining FEDs to the CC list so that all FEDs have visibility into all the reviews, but clearly know which they are accountable for completing.

  3. We agree to acknowledge all comments in a code review either by responding or using the ack or done checkbox to let the reviewers know the comment was considered or acted upon.

  4. Story owner (person assigned to story) is responsible for resolving merge conflicts in their code reviews. Team members agree to ask permission prior to handling any merge conflicts or pushing any changes to another developer's patchset.

  5. When a developer from outside of IBM has requested a change to the community agreed upon design, we agree to set up time to review the changes with the UX designers during the weekly casual playback to assure the UI implementation is consistent with existing/agreed upon patterns.

  6. We agree to show our work for design sign-off during the weekly playback once our story has is ready for review and moved to the under review pipeline.

Definition of Done

Our work is considered complete and can be closed when:

  1. A research story has been completed and an ugly wire is ready for the design phase

  2. A design story has a prototype that has been tested with end-users and validated with Subject Matter Experts (SME)

  3. The prototype has been shared with the OpenBMC community (using the OpenBMC email list and/or Discord) and as Design Review Project story in the webui-vue repo

  4. A FED has coded the work and presented the finished product to the design team for sign-off

  5. The code has been reviewed and merged to either the downstream or upstream branch

Design Story Workflow

Story Progress

  1. Stories are shared between the cross-functional team to reduce knowledge silos and information dump overhead

    • GUI Research label indicates that the the story is ready for, is in, or has completed the Research phase
    • GUI Desgin label indicates that the the story is ready for, is in, or has completed the Design phase
    • GUI FED label indicates that the the story is ready for, is in, or has completed the Implementation phase

  2. Stories will be assigned and moved to the Sprint +1 pipeline during bi-weekly sprint planning

    • Unassigned stories in Sprint + 1 can be picked up by any team member if they have completed their sprint commitment

  3. Stories are added to the Current Sprint pipeline when the story is being actively worked and discussed at daily stand up

  4. FED stories are added to the Under Review pipeline when:

    • The Gerrit review has been created
    • The Resolved by <link to review> has been added to the GitHub story
    • Reviewers have been assigned to the Gerrit review

Blocked Stories

A story that cannot move forward will:

  • Be associated with the blocked story using ZenHub
  • Have aBlocked label
  • Contain relevant information about why the story is blocked in the story description section

Invision workflow

Details for each section can be found in the Invision usage box note

Style Guide

For documentation purposes, as FEDs implement updates to the Bootstrap library, they consult these screens using the Inspect feature to fulfill design updates to the products library of component

Usability Testing

For testing purposes. All screens being user-tested should be added to this project so that the research team has a designated project to find each flow they are helping test. Each flow is broken out into a "section" populated with low-to-mid-fidelity screens.

Release

This is for hand-off, final flows, and documentation purposes organized by features as "sections". All flows in this project are considered code-ready and high-fidelity. This is the standard the FED's will try to develop to, so try to cover all instances a user might see in this project.

Concepts & Backlog

For storing future functionality and new ideas to explore or test at a later date. Personal Scratchpad (Optional) - Use this for any quick ideas and anything you want to share and keep track of more than just a screenshot.

Comments and feedback

  • Comments and feedback on the workflows should be added to the GitHub story
  • Invision comments will be added to the GitHub story if they have a historical value avoiding any unnecessary data entry

OpenBMC webui-vue repo design review story

  1. Create a story when the design has a use case and is ready for community feedback
  2. Add the story the the Design Review project
  3. Each iteration of the design should be in a new comment and include:
    • A title with the feature name and iteration number. For example, Date and Time - Iteration 2
    • Any description or information required to help clarify the changes to the community
    • A screenshot for each screen in the workflow
  4. When the design has been implemented by the front-end developer, add the GitHub story link to the Gerrit review
  5. The story stays in the In Progress column of the Design Review project until the story has met our Definition of Done.
Clone this wiki locally