Merge Request Report Widgets Working Group

Attributes

Charter

The working group ensures consistent alignment and development of all Merge Request (MR) Report Widgets. By synchronizing a collection of independently created widgets into a single report region, a code reviewer should have an easier time reviewing the merge request analysis and determining next steps.

The working group is tasked with creating a joint codebase where consistency is at the core of each widget. It’s enforced and achieved by the codebase and established APIs.

Business goal

Drive forward the adoption goals through usability by facilitating improvements to merge requests that will positively impact the shared FY22-Q3 KR between Product and UX. By following the UX Framework, we ensure the level of maturity expected by customers dealing with merge requests. From now on, we will have clear and strict guidance to ensure sustainable and consistent growth for the MR Widget ecosystem.

The main target of the working group is not to implement everything themselves but rather keep the effort moving across the frontend engineering and UX groups in a constant pace and pick up key tasks.

Scope and definitions

Merge Request Reports Region

• Area of the merge request with summaries of analysis done and proposed changes. This area resides in the *Overview- tab, between the description and comments or system notes.

Merge Request Widget Extensions

• Each piece of software that presents summarized information for analysis performed.

Merge Request Widget Extension Component (docs)

• Reusable component to allow each extension to customize the presentation of the information while still ensuring a consistent user and developer experience for all extensions attached to the merge request.

Exit criteria

• Shepherd the implementation and redesign of 10 extensions (full list) that will be ported to fully use the new shared MR Widget Extension Component.
• The shared component follows the Report regions design guidelines defined in the Pajamas Design System.
• The documentation reflects the capabilities of the shared component.
• Ensure there is clear documentation written for extending the component.

Results

Documentation outcomes

• DRI List (Eng. and UX)
• Component technical documentation
• Contributing further and extending

Product outcomes

The screenshots below illustrate the Merge Request Report Widgets before and after the work delivered by the Working Group.

Roles and responsibilities

The functional leads will be responsible for:

• Representing the needs of individual stakeholders in their department/sub-dept.
• Gathering and consolidating feedback on specific proposals from their department/sub-dept.
• Communicating the output from the working group (if any) and answering questions from their dept/sub-dept.

Ideally, the functional lead is someone who is an IC working in the affected groups, but anyone capable of representing a group, department, or sub-department in the fashion mentioned above is welcome.

View page source - Edit this page - please contribute.