Skip to content

Nonnegative integer weights in issuable sidebar

Dennis Tang requested to merge 3969-nonnegative-integer-weights into master

What does this MR do?

  • Adds support for defining non-negative integer weight values in the issue/board sidebars
  • Supports quick action via issue comments
  • Validates weight values

GIF Demo

3969

Tasks

Frontend development 

#### Planning development
- [x] Check the current set weight of the issue, does it fit your estimate?
- [x] Are all [departments](https://about.gitlab.com/handbook/engineering/#engineering-teams) that are needed from your perspective already involved in the issue? (For example is UX missing?)
- [x] Is the specification complete? Are you missing decisions? How about error handling/defaults/edge cases? Take your time to understand the needed implementation and go through its flow.
- [x] Are all necessary UX specifications available that you will need in order to implement? Are there new UX components/patterns in the designs? Then contact the UI component team early on. How should error messages or validation be handled?
- [x] **Plan your implementation:**
    - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-ce/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. Its a good idea to go through your plan with another engineer to refine it.
    - [x] **Backend:** The best way is to kickoff the implementation in a call and discuss with the assigned Backend engineer what you will need from the backend and also when. Can you reuse existing API's? How is the performance with the planned architecture? Maybe create together a JSON mock object to already start with development.
    - [x] **Communication:** It also makes sense to have for bigger features an own slack channel (normally called #f_{feature_name}) and even weekly demo calls with all people involved.
    - [x] **Dependency Plan:** Are there big dependencies in the plan between you and others, then maybe create an execution diagram to show what is blocking which part and the order of the different parts.
    - [x] **Task list:** Create a simple checklist of the subtasks that are needed for the implementation, also consider creating even sub issues. (for example show a comment, delete a comment, update a comment, etc.). This helps you and also everyone else following the implementation
- [x] **Keep it small** To make it easier for you and also all reviewers try to keep merge requests small and merge into a feature branch if needed. To accomplish that you need to plan that from the start. Different methods are:
    - [x] **Skeleton based plan** Start with an MR that has the skeleton of the components with placeholder content. In following MRs you can fill the components with interactivity. This also makes it easier to spread out development on multiple people.
- [x] **Security** Are there any new security relevant implementations? Then please contact the security team for an app security review. If you are not sure ask our [domain expert](https://about.gitlab.com/handbook/frontend/#frontend-domain-experts)
During development

 Check off tasks on your created task list to keep everyone updated on the progress
 Share your work early with reviewers/maintainers
 Share your work with UXer and Product Manager with Screenshots and/or GIF's. They are easy to create for you and keep them up to date.
 If you are blocked on something let everyone on the issue know through a comment.
 Are you unable to work on this issue for a longer period of time, also let everyone know.
 Documentation Update/add docs for the new feature, see docs/. Ping one of the documentation experts/reviewers

Finishing development + Review

 Keep it in the scope Try to focus on the actual scope and avoid a scope creep during review and keep new things to new issues.
 Performance Have you checked performance? For example do the same thing with 500 comments instead of 1. Document the tests and possible findings in the MR so a reviewer can directly see it.
 Have you tested with a variety of our supported browsers? You can use browserstack to be able to access a wide variety of browsers and operating systems.
 Did you check the mobile view?
 Check the built webpack bundle (For the report run WEBPACK_REPORT=true gdk run, then open webpack-report/index.html) if we have unnecessary bloat due to wrong references, including libraries multiple times, etc.. If you need help contact the webpack domain expert
 Tests Not only greenfield tests - Test also all bad cases that come to your mind.
 If you have multiple MR's then also smoke test against the final merge.
 Follow up on issues that came out of the review. Create issues for discovered edge cases that should be covered in future iterations.

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Closes #3969 (closed)

Edited by Inactive Account

Merge request reports