Week 9 started on Monday by dealing with the flagged GitHub accounts. As suggested by Dr. Wurst, I created a support ticket in the account and said that I was a student researcher testing out the GitHub platform for an open source project and if they could unflag the account and to contact Dr. Wurst if they had any questions about the project. I also included the issue of issue cards on project boards getting automatically removed by a spam filter. I copied this response for each one of the testing accounts so I ultimately filed 4 support tickets with GitHub. After that I tested out Dr. Jackson’s question about if shop managers on GitLab had the ability to manage their own subgroups if they are given owner permissions from the parent group owner. I tested this under the testing GitLab group by removing the shop manager account from the top-level group, creating a new shop subgroup, and adding the shop manager as the owner. This worked the way I thought it would and the shop manager was able to create subgroups within the shop subgroup and could add new members that weren’t in the parent GitLab group. I updated the GitHub issue card with confirming this finding. Then, I went on to read Dr. Jackson’s response to my earlier question of if it was still worth it to create documentation for GitLab Free based on his earlier response that GitLab Free doesn’t allow the creation of multiple issue boards and this would impact our use of the platform. Dr. Jackson’s detailed response included different ways of having workflows with the one issue board limit on GitLab Free. I ended up drawing some of these out on a whiteboard to visualize the concepts. I kind of like the concept of Dr. Jackson’s second option of having one board at the LFP level and that would be used by all of the shops. Although he says it is a disadvantage, right now I like the idea of all shops using one unified workflow as it makes documentation simpler and makes sure everyone is following the same steps to contribute to the projects. One question I have from this is how do the shop level boards look with this option or is it only just the one board in the LFP group? I also listened to the podcast he recommend about why a company switched from GitHub to GitLab. I found it pretty interesting and what they were saying mostly goes along with the differences I have found between the two services. I did like hearing from the perspective of someone who has a self-hosted instance of GitLab as this hasn’t been something I have been looking into but was interested in how this worked. Finally, Monday finished with discovering that our GitLab Gold membership wasn’t renewed properly and that we don’t have the Gold features available to us currently. This is a pretty big issue as it limits what I am able to test to just GitLab Free features. I emailed Dr. Wurst about this and he submitted a support ticket. 

For the rest of the week I checked to see if the GitLab Gold or the GitHub support tickets were updated. On Sunday I got a response from GitHub support to all of the support tickets saying that having multiple user accounts was against their terms of service and that they would remain flagged. I emailed Dr. Wurst about this and he would contact GitHub Education to see if there was anything they could do to help us. The GitLab Gold membership still hadn’t been fixed yet at this point. After looking at those, I went back to the diagrams I had been working on the previous week. I updated some of the GitLab diagrams to be consistent and fix an issue that it looked like the shop manager had to add themselves to a group which they don’t have to do. I then looked at some of the other documents in the community section of the LFP organization on GitHub to see how Dr. Jackson had formatted the other documents and what information to include. One thing I have a question on is what is the DCO and do I need to sign off on this for the commits I will be making to the project? Another is what to include for the licensing information at the bottom of the document? I then looked at the question Dr. Jackson had about if GitLab had an equivalent to the GitHub Probot framework for creating and using bots across the service. I found that although it seems possible to create bots on GitLab, they don’t seem to have a framework yet like GitHub does. 

Week 10 was short. On Monday I looked at the email response from GitHub Education regarding the multiple testing accounts. I found their response to be unhelpful to our situation and that their education features weren’t what we are looking for in testing permissions and project configurations for LFP. I took a quick look at the new website that Dr. Wurst created for LFP and how it currently links to the GitHub organization. I also read some of the principles listed on the LFP GitHub Community section like the Agile principles and the “FOSSisms“. I found the FOSSisms to be particularly interesting to read about with the process of contributing and working in open source projects, especially with how to get started with contributing to an open source project since that’s what I have been learning with this project. 

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Last week started on Tuesday by meeting with Dr. Wurst. In our research meeting we discussed various topics from the previous week’s work including the story mapping tools and the continued discussion on which platform to use for LibreFoodPantry for communications. We decided that based on my findings and what we currently know, draft.do is still the best story mapping tool and that we will start using this to transcribe the LFP user story map created during the June story map using this and I should update the GitHub issue card regarding this. Frequently when talking about various things it seemed that we will need a server for hosting various tools for the LFP projects so one thing I will look into is what services (if any) have free server time for open source projects. After discussing the workflow documentation I created for the shop setups I learned I needed to create diagrams for these and research or create my own way of modeling different things in GitLab and GitHub such as repository structure and permissions. 

Wednesday I briefly updated the issue card regarding if we are still creating documentation for GitLab Free since it has restrictions on the number of issue boards you can create. I also updated the story mapping card with what Dr. Wurst and I discussed the previous day about reaching a decision on which tool we are using so we can move forward with that. 

Friday I looked at the updates to the story mapping issue and started working on transcribing the user story map created during the June retreat from the pictures taken and put onto the Google Doc during the retreat. I found that this went pretty smoothly using draft.do and following the format for the shop-level workflow we previously did in this tool made it easy. I updated the issue on GitHub with my work in progress story map and asked for it to be reviewed to make sure I got the colors and card positions correctly. I then tried pushing the workflow documentation to the LFP/Community GitHub repository and ran into a permissions error so I had to email Dr. Wurst to get write permissions for the repository. I switched the documentation extension over to .md so it would be recognized as Markdown by GitHub and the operating system. I then started working on creating diagrams for the various setup workflow documents. I started out by drawing the initial diagrams on a whiteboard then I would transcribe them over to a digital format to be stored in the GitHub repository. I tried using the yEd tool that Dr. Wurst suggested for creating diagrams and found that it was a bit tricky with yEd being a lot more restrictive in where you can place things after previously using draw.io for making diagrams. Although after using it for a couple of hours, I found that it is easier to have consistent formatting with this tool versus draw.io and I’m starting to warm up to it more. One thing I want to figure out is where and what format should these diagrams be stored in the repository and should they be included in the setup documents. I ended up finishing the diagrams for both GitLab Gold and GitLab Free, along with refactoring the documentation, and started working on the ones for GitHub Free. When I went to use the shop manager test account on GitHub I found out that all of my GitHub testing accounts had been flagged by some kind of auto spam detection bot so I emailed Dr. Wurst regarding what I should do about this and ended the week with this. Next week I will continue finishing up the setup diagrams and documentation and move on to the workflow ones, along with responding to Dr. Jackson’s additional questions on GitHub.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Last week I had three main areas I wanted to focus on: Creating or at least starting documentation for the workflows, looking at the different story mapping tools, and testing project / issue boards on the different platforms. 

I started on Tuesday by creating the documentation for the different workflows. I began with creating setup instructions for how to create the shops on each of the platforms. Throughout this process I used the new Shop-Level Workflow story map that we created previously and I found that this was very helpful especially with having the user roles above each step so I knew who has to perform which actions. As I was creating the documentation I was going through the steps outline in the story map on each platform with my account and the shop manager account. I did run into some issues doing this such as on GitLab the selected permission level for the shop manager in the LFP group can’t add new members or create shop subgroups, something that the story map says the shop managers should be doing. I commented on this issue on the GitHub issue card and it will probably be something that trustees have to do instead of the shop managers. By the end of Tuesday I had created the initial setup documentation for GitLab Gold and GitHub Free. 

Wednesday I read Dr. Jackson’s reply about the shop managers issue and tested out his question about whether shop managers can create their own subgroups if a trustee creates a shop subgroup for them and makes the shop manager the owner. I found that this is possible and most likely will be the solution to this permission issue. I added documentation for GitLab Free which differs slightly as it would be a standalone group instead of a subgroup of LFP. I also separated the documentation so each platform has its own document instead of having all three together. I then copied the text over and converted the documentation to Markdown so it can be pushed to the LFP GitHub organization. After that I moved on to testing the issue and project boards on GitLab and GitHub. I did this by creating boards for each test group and adding some issue cards and moving them around. I found that basic board functions worked the same on all three platforms. The biggest difference between GitLab and GitHub is that you can create labels in GitLab and that cards can automatically move as labels change or the labels will change as a card is moved across a board. This seems very helpful as it moves the card on multiple boards that use the same labels, making organization more consistent. One problem I found was that GitLab Free has restrictions on the number of boards you can create which may be a problem with the workflow we’ve designed for the shops.Saturday I started testing out the different story mapping tools. I created a new Google Sheet and created a row for each one of the features that both Dr. Wurst & Dr. Jackson were looking for in these tools. I then went through most of the story mapping tools listed on the GitHub issue card. The tools I tested were: cardBoard, miro, LeanBoard, FeatureMap, Draft, Craft, and StoreiesOnBoard. Out of all of these I tested I found that miro and Draft had the best feature sets without having to pay to use the tools. Out of all of them LeanBoard was the only I found to have direct issue tracker integration (it is a GitHub marketplace app). FeatureMap had some good features such as being able to assignee cards to users which I think would be helpful for claiming stories in the shop groups. Currently it looks like Draft is still one of the best options so far for free. Next week I will start on creating documentation for the shop workflows and possibly continue with the story mapping tools.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

I began last week on Tuesday by preparing for the workflow story mapping session that would be held the next day. I did this by first quickly exporting all of the VMs I had created to an external SSD that way we could have them on our laptops at the meeting if we wanted to use any of the test accounts in their own environments. I quickly tested importing one of them on my laptop just to make sure this worked which it did very easily. I then finished the GitHub workflow testing as I wanted this done before the next day’s meeting. I ran into another error when I was trying to push commits to the feature branch with a shop developer account. I figured out that this issue was caused by the shop developers accounts’ not having permissions for the test shop repository. By adding the two shop developer accounts to the repository as collaborators and giving them write permissions this fixed the push issues and last week’s issue of not being able to create new branches in the repository. The reason for this problem was because when creating the GitLab group it automatically takes permissions from the group level and automatically applies them to the repositories, so I didn’t realize I needed to do this separately in GitHub. I tested this again in GitLab by creating a new repository to be sure and it does copy the permissions over for individual repositories. GitHub has separate permissions for repositories than organizations (Unlike GitLab) and it needs to be manually set, something that I didn’t do initially. After doing this I could successfully implement the rest of the workflow in GitHub Free and found it worked the same way as GitLab Gold. 

Wednesday was the story mapping meeting. During that meeting Dr. Wurst and Dr. Jackson created the entire story map for the shop-level workflow. I found this to be very helpful as it shows the complete sequence of events from applying to be a shop through developing stories to closing the shop. Even better is that the user roles for each step is marked clearly above each step in the story map. I am sure this will help me immensely in future testing and alleviate the issue of asking which users are responsible for performing which steps of the workflows when I am testing them. I found it was great to observe and participate in another story mapping session and to see how these workflows are developed. After developing this we briefly discussed any remaining questions I had and I was assigned new tasks including how to migrate issues from GitHub to GitLab when importing projects along with moving on to creating documentation for setting up shops and the processes involved. 

Friday I decided to test the original workflow on GitLab Free just to be consistent and make sure it worked on all 3 of the platforms before continuing. I found that it worked exactly like the GitLab Gold testing did and there were no issues with it. Dr. Jackson asked if I had any notes on testing so I then went through my old testing notes for GitLab Gold and GitHub Free and formatted it to be consistent and show which user was performing which step. I posted a link to the Docs file with these onto the issue card on the LFP GitHub. Dr. Wurst invited me to a LFP Discord server he created so I joined this and helped him setup his microphone. Once we got this working we briefly discussed project boards and moving cards and further testing that I would need to do on this going forward with the project / issue boards on the 3 platforms. Finally I figured out how to import issues from GitHub to GitLab. The reason it wasn’t done for the BEAR-Necessities-Market repository earlier was because forking the project first on GitHub removes the issues from the project. I found that if you directly import a GitHub project into GitLab from your own account it copies all of the issues over.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.