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.

Last week started again with another research meeting with Dr. Wurst. One of the things we talked about was the diagram I had previously created for the proposed workflow. Dr. Wurst wanted to see if it was possible to import and export the diagram using this tool so that it could be added to the LibreFoodPantry repository on GitHub and be in a file format that works with version control for future modifications. One question I had was how should I setup the different local GitLab and GitHub accounts during testing for the workflow for the local repository stuff that’s supposed to happen on certain users’ computers. We ultimately decided that it would be best to create a virtual machine for each account that way it keeps the browser accounts and GitLab / GitHub accounts separate from each other. We also talked about trying to fork Dr. Jackson’s BEAR-Necessities-Market repository from GitHub and try to get GitLab’s CI to run on it. Finally we talked about different roles in the whole workflow such as shop managers and who is the product owner and what guests should be able to do as far as creating issues for a project. 

I started off Wednesday by creating the virtual machines for the test accounts so I could get started with testing out the workflows. I used VirtualBox since it’s free and used Ubuntu 18 LTS as the operating system. After installing the OS, I put Java on each VM, along with Git and a basic text editor. I then signed into each account and soon started working on the workflow. I also tried importing and exporting the diagram in Draw.io and found it can do this as an XML filetype which will work with version control software. While testing the GitLab Gold workflow I hit a snag when it came to creating the feature branch. I didn’t know if the shop manager or the shop developer was supposed to create it so I emailed Dr. Wurst and paused work on this for the day. In the meantime I created GitHub test accounts so I could start working on testing the workflow in GitHub. I also forked Stoney’s BEAR-Necessities-Market into the test GitHub account and imported it into my GitLab account so that I could ultimately enable GitLab CI on it.

Thursday I learned how to move a GitLab project from my account into a group. I did this with the import of BEAR-Necessities-Market from GitHub. I then created a config file to enable GitLab CI and eventually got this to work for the repository. I did this by looking at the config file that was created for Travis CI as it was similar and translated the instructions over to GitLab. I found that GitLab does do its CI config differently than Travis but by reading GitLab’s documentation I figured out how to do what I needed to. I also tested out what permissions guest users have in GitLab with issues and issue boards. I didn’t find anything surprising here, guests can create and comment on issues and that’s about it. 

Friday Dr. Wurst got back to me and I finished testing the workflow in GitLab Gold. I found that everything worked exactly as planned and that it was a smooth process. Dr. Wurst suggested we should have a story mapping session next week for the workflow roles which I thought was great as I am beginning to have questions about who does what during this proposed workflow and the initial diagram doesn’t answer all of these questions. I briefly played around with the security dashboards for the GitLab import of BEAR-Necessities-Market and got it to report dependencies and any security vulnerabilities. This was easy to do with GitLab’s template for this. I also began to test the candidate workflow on GitHub. This is where I began to run into problems as GitHub doesn’t have the same levels of permissions as GitLab does (more on this issue next week). This altered the workflow as the shop manager had to create the feature branch instead of the shop developers. I stopped for the week after this and will continue testing on GitHub before the story mapping meeting on Wednesday.

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 started last week by meeting with Dr. Wurst (my project advisor) to go over what I had done up until that point and to figure out what I should be doing going forward with my research. We mainly discussed the new proposed candidate workflow that was created during the LibreFoodPantry (LFP) Retreat after I had left. Most of that discussion was about the two main roles in the diagram, the trustees and the shop managers. It was decided that the trustees would be the people who maintain the LibreFoodPantry project and that the shop managers would be instructors who are teaching a course and developing for the project for a semester. The shop managers would fork a copy of the repository they are working on into their own “shop” for their class where it would be worked on by student shop developers (another user role). Finally there is a client / user role that has basic access to the LFP group. We also discussed the GitLab permissions for each of these roles, which is different depending on which GitLab group we are looking at as there is different permissions for the same role in the LFP group and the shop group. We decided that I should be building this workflow out in all 3 platforms (GitHub Free, GitLab Free, and GitLab Gold) and document the process and any issues. We anticipated issues trying to implement this in GitHub as it doesn’t have the same permission levels as GitLab which is what the workflow was created with. I also needed to update the features table as we previously discussed the previous week so that all the features in the same row are related across platforms and that they use the specific naming that the platforms use. Finally, I was to try and create a simple GitLab repository and implement GitLab’s CI in a simple Java Gradle project to see how this worked. We also decided that we would have regular meetings every week on Tuesday for the rest of the summer.

On Wednesday I created a new table using Google Sheets as I found that the rows align much better in a spreadsheet than a Google Docs table. I copied and pasted all of the bullet points from the 3 platforms from the old table into the new one. I then rearranged them in color order. I finally went through each one and started renaming the features to be more consistent with how its respective website names it in its support or documentation pages.

Thursday I finished up with the table and it was nearly done except for a few little questions for Dr. Wurst in our next meeting. I also created a digital version of the proposed candidate workflow diagram using Draw.io as I wanted a cleaner looking version instead of the whiteboard picture from Google Drive. I emailed Dr. Wurst the diagram to check if I created it correctly and had a little question about why one of the branch symbols was located in the diagram. I finished Thursday by creating a GitLab Gold repository and made a GitLab CI configuration file. I cloned it to my desktop and converted it to a Gradle project the way we did this spring in CS348 using some documentation from the course’s Blackboard page. I ran into a problem that others in my class had previously with Gradle not working correctly on Windows.

Friday I fixed the Gradle not working issue using a page from stackoverflow. I then got GitLab CI to work on this project, as it was previously failing due to a fix I implemented to try and get Gradle to work. I found that GitLab’s website provides great documentation to show exactly where the failure occurs in a CI pipeline. On Friday I also received an email from Dr. Wurst that forwarded a document from another professor who had a student that also researched GitHub vs. GitLab. I looked at the document and it compared what they thought were the most important features, some of which I hadn’t seen yet so I looked at them on GitHub and GitLab’s websites and added them into my features table. I did find this document to be helpful as it contained new information I hadn’t come across yet. I decided that the table was done and moved on to testing the candidate workflow. I started this by creating 4 Google Accounts, 1 for the shop developer, 2 for the student developers (so I can have two student local repositories to push and pull from) and 1 client / guest account. I documented the usernames and passwords in a Google Sheet so that others in the LFP group can use them. I then created GitLab accounts for these test accounts and added them to the testing group we created in GitLab Gold (I used my account to add them to the LFP test group and the shop manager to add to the class shop group to simulate how it would actually be done with the trustee and shop manager roles). I am using the test group we created in GitLab Gold as the LFP group and I made a sub-group in this that acts as the shop group. One problem I noticed with this is that if we are going to create sub-groups for the shop classes within the LFP group on GitLab, there would be permissions issues with trustees having access to the shop which would be a course taught at another institution. I used my GitLab account for the role of trustee since I was an owner in the testing group. I then created a test repository in the test LFP group under my account and forked it into the shop with the shop manager account. At this point I stopped for the week as I was unsure of how to proceed with testing the workflow since it involves multiple shop developers cloning, pushing, and pulling to their local computers. This would mean I need multiple local GitLab repositories with different user accounts and I wanted to ask Dr. Wurst the best way to do this, I thought that creating a VM for each account would be the best way of doing this.  

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 Wednesday night I finished my comparisons between GitLab Gold and GitHub Free. I’m happy that I managed to get through all of the features before the LibreFoodPantry retreat the following day. I found that most of the features left for GitLab Gold did not have comparable versions in GitHub. This is more of what I was originally expecting and so the remainder of the table has a lot of features marked GitLab Gold exclusives. There was also a trend with the GitLab features that most of them would relate to one overall feature such as having Epics so since GitHub doesn’t have a native Epics feature it wouldn’t have any advanced features related to managing and tracking Epics like GitLab does. I also found that some of these features were harder to compare between platforms since most of them were more advanced, enterprise grade features than the earlier ones. This is again also due to how well the documentation for both platforms explains the features and how to use them.

Thursday was the beginning of the LibreFoodPantry Retreat. We started off by going to lunch and having casual conversations before the meetings began. I enjoyed this as I got to know everyone a little bit before getting down to business. Once we got back from lunch, all of the members who taught a course last semester developing software for LibreFoodPantry had a retrospective detailing the good and the bad and developing ideas and solutions to the issues. I found this process interesting to observe, especially after learning about software management processes this spring and now I got to see it in action with a real project. My advisor and I briefly described our summer research project and how it relates to what was currently happening with LibreFoodPantry. Through the first day I began to learn about issues that the group was encountering and areas where I can focus my research. Some items I will need to look for is assigning issues to multiple people or groups.

Friday continued with the second day of the LibreFoodPantry Retreat. I came in after lunch and immediately saw a whole whiteboard along one wall covered in sticky notes with labels. I soon found out that this was all of the user story mapping that was worked on while I wasn’t there. Dr. Jackson went through the whole story mapping briefly with me, explaining the user groups and the features and how they all fit together. It was eventually decided that this story map should be stored in the LibreFoodPantry organization/group on whichever platform we end up using and I should try to create a small version of this board on each platform. We then moved on to discussing infrastructure and workflow. Additional things I will be looking at now will be setting up continuous integration in GitLab and see how this works. I will also be fixing my platform features table so that features have consistent naming with their respective platform and that they are directly comparable across rows. Overall, I really enjoyed going to the LibreFoodPantry Retreat and seeing the processes and discussions involved in creating an open source software 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 I continued researching the features of the GitLab Gold and GitHub Free platforms. I continued going down the list of the features listed for GitLab Gold on its feature comparison page and then seeing if GitHub Free had similar implementations of these features. I originally thought that most of the GitLab Gold features would be exclusive to this platform, but to my surprise GitHub Free supports quite a few of GitLab Gold’s advanced features. I found that GitLab Gold does have some features that GitHub Free doesn’t though, some of these are either advanced features geared more towards enterprise environments, others seem to fall under more advanced user permissions such as selecting which users can approve merge requests. I found that GitLab Gold’s issue board system is much better than GitHub’s project boards with the ability to create more advanced boards than GitHub, such as a board with user assignee lists or a milestone list. I am again finding that certain features between the GitHub and GitLab platforms are easily comparable and have a direct counterpart such as requiring commits to be signed and other features are a bit more ambiguous such as supporting what GitLab calls “backlog management”. I am finding this is largely due to how clearly GitHub’s and GitLab’s websites document and explain the features the platforms offer. Another thing that I am finding that makes this comparison process harder is that the description for the feature on GitLab Gold’s product comparison page doesn’t always match exactly with the features described in the documentation it links to, or sometimes the links provided from the feature comparison page don’t go to a specific section of the online document. I have also begun to use the test groups to see for myself what features are available in these platforms. I have been mainly using the GitHub organization to compare its project board features to GitLab Gold’s issue board features as I find it is easier to actually see what’s available in GitHub than to use its website guides. I have also started to take note of what I think should be tested in the workflows between GitHub and GitLab, this includes the project/issue boards and some of the more advanced options GitLab Gold offers, along with other user permission settings GitLab has such as push rules.  I am hoping that at the meeting later this week we will refine the workflow so I can begin testing these features. I plan to finish the comparisons between GitHub Free and GitLab Gold before the meeting at the end of this week so that I have a good idea of all the advertised features of all of the platforms.

In addition to continuing research on the platforms, I also began to learn more about the LibreFoodPantry project. I did this by going through all of the past meeting minutes that were sent to me. I wanted to get a better idea and background on the project to see what decisions have been made so far and how my research into version control software fits in to this. I also wanted to this before the meeting later this week, so I could get a better idea of my purpose in these meetings.

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.