Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop LFP/Shop Workflow Infrastructure #37

Open
kwurst opened this issue Jun 18, 2019 · 24 comments

Comments

3 participants
@kwurst
Copy link
Contributor

commented Jun 18, 2019

@cradkowski is developing candidate workflows and infrastructure for the LFP/Shop setup.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jun 18, 2019

Are shop manager and product owner the same person?

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2019

Typically yes. I guess I could imagine a situation where someone would play the role of a shop manager, but someone else would play the role of a product owner. But I think the common case would be they are the same.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2019

To further clarify... Shop Manager is a role in LibreFoodPantry. They manage a group of developers working on one or more projects for (typically) a limited time. Product Owner is a role in Scrum. I would expect that Shop Managers would normally take on the role of a Product Owner. But it is possible they could delegate that role to someone else.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jun 19, 2019

If the shop group is created as a sub-group of the LFP group in GitLab then the LFP trustees have access to everything in the shop repository. This seems like it would be an issue, especially for courses at other schools. Is there really a benefit of creating the shop group as a sub-group under LFP? Does the shop group need any GitLab Gold features that it is neccesary to do this?

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2019

@cradkowski good point!

I think this is a shop manager decision. They will need to weigh the benefits of having GitLab Gold benefits against trustees having access to their shop.

As a shop manager, if privacy is my concern, I think it would be more important to tell my shop members that if they are concerned about privacy that they can and should use anonymous accounts and configure git to record a pseudonym and an anonymous email on commit messages. Because even if we kept the shop group outside the LFP, any member who makes a commit, or is mentioned in a Co-authored-by line in a commit, or who interacts with the issue tracker in LFP will have their identity revealed.

But I think we have to leave this decision in the hands of the shop manager. I could imagine cases in which a shop plans to work on multiple projects, some of which are private non-LFP projects, and they'd prefer to have one group to manage all their efforts.

@kwurst

This comment has been minimized.

Copy link
Contributor Author

commented Jun 21, 2019

Comment from POSSE attendees in June 2019:

GitHub vs. GitLab - POSSE people didn’t seem to have a strong opinion either way

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jun 28, 2019

@kwurst @StoneyJackson I've already tested the previous workflow diagram (created during the June retreat) in GitLab Gold and GitHub Free. Do you think I should re-test on these platforms using the diagram we've developed during #39? Some steps aren't as applicable like applying to LFP but there are a lot of new ones related to project / issue boards.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

@cradkowski Do you have someplace a description of the tests you did and their results? If I could take a look at what you did I might be able to answer this.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jun 28, 2019

@StoneyJackson Here you go: https://docs.google.com/document/d/1gCdrGShrV-lCEOO1_tlOuNwPAng8ncs1s-ZjlsDiE2k/edit?usp=sharing

It is ordered chronologically as I went through each action, I put in bold the user role that was performing each step.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jun 28, 2019

@StoneyJackson You can import GitHub issues into GitLab when you import the repository with GitLab's tool. I think the reason it didn't work before for BEAR-Necessities was because I forked that into the GitHub test group before importing it to GitLab which got rid of the issues. I created a new test repository in GitHub and directly imported it to GitLab without forking it first and it seems to work fine.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2019

@cradkowski summarizing our discussion on on discord regarding testing the workflow in light of the new story map of the workflow... I think we decided that we need testing of the boards: creating them, adding cards, moving cards, moving cards between boards, boards sharing cards, etc. Correct me if I'm wrong. That was yesterday, and my memory isn't great.

Also nice testing log.

And thanks for the information about importing issues. So we'll need to make sure that we do that as you described.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2019

In this repository (Community), I have created some initial structure for documentation. I thought I'd quickly document it before I go camping in case you want to put documentation in these locations.

.
├── docs
│   └── dev
├── license-snippets
└── project-template
    ├── bin
    └── docs
        ├── admin
        ├── api
        ├── dev
        └── user

The top-level docs/ directory is for documentation that is shared between all projects. This is probably where the workflow documentation should live. More specifically, somewhere under docs/dev since it is developer documentation.

The top-level projects-template/ directory contains starter files for projects. The CONTRIBUTING.md will have links into the top-level, LFP-wide, docs/ . So when new projects are started, they will copy these files over, and they will already be linked to the LFP-wide documentation.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jul 2, 2019

Maintainer permissions in GitLab does not allow the creation of subgroups. This means that the shop managers will not be able to create their own shop subgroups in LFP, the trustees will have to do that for them. This will need to be updated in the shop-level workflow story map as well, as we currently have it that the shop managers create the subgroups in LFP and add their shop developers to it. See this for more info on group permissions: https://gitlab.com/help/user/permissions#group-members-permissions

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2019

That sounds like a reasonable change. Can we make shop managers an owner (or some role that allows... ) over their shop subgroup so they can add other subgroups if they like?

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

Yes, trustees can set the shop managers as an owner of the shop subgroup and that allows shop managers to create subgroups within their shop.

There is also a similar issue as above. In GitLab maintainers cannot manage group members. Trustees will have to also add all shop developers to the parent LFP group in GitLab as the shop manager cannot do this as a maintainer.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

Shop-level Workflow story map changes

These two cards need to be changed on the shop-level workflow story map to either have the trustees do it or change how this is done in the workflow, as the shop managers can't do this in GitLab.

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

@StoneyJackson

I tested out the project / issue boards on all 3 of the platforms. On all platforms the creation of the boards, labeling the board columns, having the same issue card on multiple boards, and adding, moving, and ordering around the cards are the same.

The biggest difference is on GitLab when you create a list (column) on the board you do this by creating a label for that list. All issue cards that you tag with this label are automatically moved into this list. You can also move cards across the board and it automatically updates the issue card's label according to the list(s) it is in. These labels work as a hierarchy with repository boards inheriting the same labels from the group-level. They are consistent across multiple boards at different levels in a group. If you move a card in a shop-level board list with the same label as a list in a repository-level sprint board it automatically moves the card in the other board. This seems really convenient as you only need to move a card in one place instead of on multiple boards. GitHub doesn't seem to have an equivalent feature besides its basic automation for to do, in progress, and done. This means manually moving the cards around on multiple boards.

One thing to note is GitLab Free only allows you to create one issue board at each level so you can only have 1 group-level (shop-level) issue board and 1 repository-level board, this might conflict with having an issue board for each team during sprints. It doesn't seem like you can create subgroups to get around this.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

There is also a similar issue as above. In GitLab maintainers cannot manage group members. Trustees will have to also add all shop developers to the parent LFP group in GitLab as the shop manager cannot do this as a maintainer.

@cradkowski Can shop managers manage group members on a subgroup they have created? For example, suppose we create subgroup LFP/Shop1 and give ShopManager1 ownership of it. Can ShopManger1 create subgroup LFP/Shop1/Team1 and add members to it who are not members of LFP?

(sorry... been camping... about to again :))

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

The biggest difference is on GitLab when you create a list (column) on the board you do this by creating a label for that list. All issue cards that you tag with this label are automatically moved into this list. You can also move cards across the board and it automatically updates the issue card's label according to the list(s) it is in. These labels work as a hierarchy with repository boards inheriting the same labels from the group-level. They are consistent across multiple boards at different levels in a group. If you move a card in a shop-level board list with the same label as a list in a repository-level sprint board it automatically moves the card in the other board. This seems really convenient as you only need to move a card in one place instead of on multiple boards. GitHub doesn't seem to have an equivalent feature besides its basic automation for to do, in progress, and done. This means manually moving the cards around on multiple boards.

This sounds very handy. This would allow folks to update labels on a card, and the card would move to the correct column on a board. Very nice for tracking progress.

One thing to note is GitLab Free only allows you to create one issue board at each level so you can only have 1 group-level (shop-level) issue board and 1 repository-level board, this might conflict with having an issue board for each team during sprints. It doesn't seem like you can create subgroups to get around this.

OK, I tried this on GitLab with some private groups and subgroups and without Gold. I was able to create a group-level board and a subgroup-level board with different columns (one had todo and doing the other had only doing). I was also able to have a project with yet another board inside the subgroup, that had only open and closed columns.

To summarize, I found that GitLab (free) allows:

  • 1-board/(sub)group
  • 1-board/project
  • projects and subgroups inherit the labels, and therefore possible columns, from their parent group.
  • Group boards provide a view of all issues in all projects in that group and all subgroups.

NOTE: Their docs say that group-level boards is a premium feature, but I don't have a premium account. So... 🤨

From the perspective of boards, it sounds like GitLab free would not work well for us. But but both GitHub and GitLab Gold would, because they allow multiple boards per project and per organization/(sub)group.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

Another related item...

As I understand it, Probot is a framework for developing bots for github that can be connected to projects to perform automated tasks. There are several very useful bots already implemented that I would like to take advantage of. So two questions...

  • Is there an equivalent to Probot in the GitLab community that allows for the creation of more automated tools? Even if we don't create them, we could benefit from tools created by others in the future.
  • Is there functionality in GitLab that is equivalent to the more popular existing Probot bots?
@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2019

@StoneyJackson

From the perspective of boards, it sounds like GitLab free would not work well for us. But but both GitHub and GitLab Gold would, because they allow multiple boards per project and per organization/(sub)group.

Based on this, do you think it's still worth creating workflow documentation for GitLab Free?

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2019

@cradkowski

TLDR: I think GitLab Free is still in the running.

Hmm... Let's explore how multiple teams might work with a single board on GitLab Free.

  • Option 1: Each team could have a separate columns for their "in sprint", "todo", "doing", and "done". That sounds like way too many columns. Not a good option.
  • Option 2: Each team could have a label for their team and label tasks and stories with their team label. Then team members can filter the board based on their team's label. This isn't entirely horrible. I could even be desirable as it would be "easy" to see what other teams are doing without going to another board. I think I might be warming to this idea. I would have to see it in practice.

Before I did this, my answer would have been "nah, don't bother with GitLab Free". But now, with option 2 above, I think we could make it work. We have to remember that this one board would be exist on the LFP project and would be shared across all shops, their teams, and their team members. The advantage is that all efforts can be visualized together. The disadvantages would be 1) the need to filter (everyone would need to be trained in the use of filters) and 2) all shops and teams must use the same workflow (i.e., for example: backlog, in sprint, to do, doing, needs review, needs merge, done). The advantage this would have over multiple boards is that cards don't need to be moved between boards.

To my last point.... In GitLab, are all issues automatically represented on all boards? If so, the movement of a card between boards might be slightly easier.


Now I have a new concern... if GitLab puts a card into a column by label, and if all issues are automatically on all boards, then if a team add a "doing" label to their card, would it move to the "doing" column on all teams' boards? If this is the case we would need to create a set of labels for each team (e.g., "t1 to do", "t1 doing", "t2 to do", "t2 doing", ...). That means setup is more complicated.

Trying to answer my own question I read this https://docs.gitlab.com/ee/user/project/issue_board.html#advanced-team-handover . This suggests that boards with common columns can be used to hand-off between teams. In their example, both teams have a "Frontend" column. This is used to hand-off an issue from a UX team to a Frontend team. I'm assuming this works because they both have a column named "Frontend". The trouble I'm having is that in the same example both teams have a "Doing" column. If the UX team, say, moved a card to "Doing" wouldn't it also show up on the Frontend team's board? Or is there some more magic to prevent that?


While looking around I found this page on GitLab which highlights one company (codepen) that moved from GitHub to GitLab and why and how they did. There is 30 minute podcast there. Very cool (listening to it as I write this). https://about.gitlab.com/2017/01/27/codepen-welcome-to-gitlab/#project-management-everything-in-one-place

@cradkowski

This comment has been minimized.

Copy link
Collaborator

commented Jul 15, 2019

@StoneyJackson

There is also a similar issue as above. In GitLab maintainers cannot manage group members. Trustees will have to also add all shop developers to the parent LFP group in GitLab as the shop manager cannot do this as a maintainer.

@cradkowski Can shop managers manage group members on a subgroup they have created? For example, suppose we create subgroup LFP/Shop1 and give ShopManager1 ownership of it. Can ShopManger1 create subgroup LFP/Shop1/Team1 and add members to it who are not members of LFP?

(sorry... been camping... about to again :))

Yes that works fine. It looks like the shop developers would need to be added to the Shop, LFP/Shop1 in order to gain access to the team, LFP/Shop1/Team1 or at least I was getting an error until I added them to the Shop. All of this is something the shop manager can do without the shop developers needing to be added to the main LFP group by a trustee.

@StoneyJackson

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

That'll work 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.