Transition to a projectV2 project board

[mreekie]

Proposed transition:

• communicate to the community prior
• Upgrade on a Friday
• As part of the upgrade, drop all closed issues older than 90? days
• After the upgrade test the automations.
• After the upgrade make sure the external mike reporting scripts
• Pick a Friday in June
  • after the community meeting during the summer vacation lull.

Risks:

• Broken automations
  • trivial to fix
• Broken reporting scripts
  • will be a test plan
• community developer confusion
  • communication (e.g., see issue identify by Phil: Update guides on use of projects/boards used by the project (2 vs. 34, etc.) dataverse#9157)
• Service Interruption
  • doing it after the comm. meeting during the summer slow months

Benefits:

• reporting will be simplified
• more information can be shown on the same board in a simpler manner.
• GitHub is pushing the upgrade

[pdurbin]

Related:

• Update guides on use of projects/boards used by the project (2 vs. 34, etc.) dataverse#9157

[mreekie]

Closing [#7](https://github.com/IQSS/dataverse-pm-transition/issues/7 as a dupe of this so I'm copying the relevant info

I had explored the use of this project

• https://github.com/orgs/IQSS/projects/48/

I had been pushing back on Ceilyn in simply running the upgrade process that github provides, but after looking again at how little there is on the new board and how easy it was to upgrade the sid team board, I'd vote at this point for using the github process and moving the sprint board first, then building on it as Ceilyn had suggested.

Note on the legacy board;
If the legacy dataverse repository is not going to be transitioned to a projectV2, then for performance sake we need to trim the "done" column.

I propose that all issues less than an arbitrary time old with a list of the ones that were dropped and the date that they were dropped.

context:

• The current sprint board has 45 cards on the board, and just under 500 cards in the completed column
• sprint data is is only useful during the sprint and needs to be captured at the beginning and end of each sprint to an external database to be useful over time.

[mreekie]

July 12th is the next dataverse project meeting.
Let's use that date as the target for sharing this idea/proposal with the team.
Then the execution date would be set for August 16th

[mreekie]

Met with Ceilyn today and showed her how things are working for the Engineering Team Sid board.
After, I created a flowchart of how we can implement it.
As we talked about it I realized that there is one big difference between the DV workflow and the engineering team and that it might be an problem

PRs

• The eng team does not introduce PRs onto the board.
• When automation introduces a new PR onto the board it does not include setting the value of the BacklogQ field. It only modifies the value of the "Status" field.
  • in order for an item to appear on the sprint board in this scheme, it needs:
    • status: to be set to a value
    • BacklogQ: to be set to an equivalent to "Prioritized"

[mreekie]

I need to think more on this. Is there still a value add here?
In the meantime, I put thoughts on paper for how we would need to transition if it did work fine with PRs. on a miro board.
https://miro.com/app/board/uXjVMtgIhAM=/?share_link_id=568090538464

[mreekie]

We may be able to do this with github actions.
It may be time to look at GitHub Actions.
https://docs.github.com/en/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management
I'll take a look

[mreekie]

Ceilyn/Mike discussiontoday:
The reason I'm bringing this up now is that the sprint board is becoming "unusable" -- super slow, very laggy. I'm thinking that it has to do with 1) too many Done items, and 2) maybe just time to migrate.

Mike Reekie
13:48
hmmm.... That raises an approach...
Just migrate the Items on the current sprint board.
Then we can keep going on the combining the boards in the background.
‼️
1

13:49
We remove all issues in the done column first that are older than I dunno - 3? months old.

13:50
I could work on that this afternoon.

• Retrieve a list of all items in the done column.
• Remove all items that were closed < 3 months ago from the list.
• Remove the resulting list of items from the current sprint board

Next Step:

• propose a list of issues to be removed from the current sprint project board, which have the status closed.

[mreekie]

Notes:

• There are multiple repositories represented in the closed state in the https://github.com/orgs/IQSS/projects/2 project. For this step the objective is to drastically trimming down the issues in the project. Most of the issues in the project come from thi s repo: https://github.com/IQSS/dataverse/issues. I'm only going to consider that repo.

[mreekie]

Transitioned this to a use case in the active rep/project
Transition to a projectV2 project board#52