In order to prepare for my Software Development Capstone project, I must be aware of my client (that is, who my group will be creating software for). This client is known as “LibreFoodPantry” – a system of various University-based food pantries, combined through their goal of using computer software to make this mission more efficient.

One aspect of LibreFoodPantry that I found particularly interesting was the status of the program. Apparently, “no software has been deployed to a client as of yet”. I had decided to focus on this aspect of the pantry (and subsequently write about it) as it performs a dual effect on me. Not only does it relieve me of the guilt that I may not bring the best software to the project, but it also excites me with the opportunity to be a “pioneer”; I will lead the way with my own codes and ideas.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

I found the architecture used in Thea’s Pantry interesting. It was nice to see the UML diagrams as they help tremendously with understanding how the architecture works. It is also nice seeing the individual pieces of the system, and then seeing them all together at the end, seeing the entire system come together. I also found the workflow interesting as well, having a new branch for every feature/fix/refractor, each being associated with a merge request when the branch is created. Then, using conventional commits, and commit merging. It is good to see this level of organization in the workflow process.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

I found something interesting on the LibreFoodPantry website was the Code of Conduct. It was nice to see examples given of positive behavior, negative/unacceptable behavior, and the enforcement responsibilities, along with the scope and the enforcement of the Code of Conduct. It shows that there is enforcement in place to keep people of negative intentions out of the project. It is also nice to see Enforcement Guidelines in place to help correct any negative behavior, so that everyone gets the same things enforced, so there is no pick and choose. It shows that the community behind the LibreFoodPantry is good, in my opinion.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

One of the things that I found surprising while going through the Thea’s pantry project was in the UserStories.md file, it includes a .PDF file of the form that the staff would fill out for each visit. What surprised was not that the form was already made or that it was included in the Markdown file but rather it had a copy of the form with strikethroughs. I found this both surprising and interesting because the form looks mostly finished so I would normally assume the version of the form on GitLab would be a polished version without any markups or strikethroughs. I chose to write about this because it made me wonder if there was more that needed to be added or fixed on the form. But seeing the strikethrough also helps me see their thought process as to which they removed or moved certain things in the document.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

After looking through the different documentations, the most interesting thing to me was the User Stories. In Software Development, I can easily imagine there are situations where we are working with a large number of files or “processes” so to speak.  The User Stories illustrate textually the different processes that should occur, in what order they should process, and what is required. This in a sense is a sort of localized version of a software flow chart, but with text instead of graphs. This would be very useful to me or to whomever works on the project. It was also surprising that some sections were further linked to pdf documents further describing the format and or changes.

Link:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/blob/main/UserStories.md

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

Getting Familiar with LibreFoodPantry

After reading the different items listed in LibreFoodPantry’s main page, the most surprising and important things to me were some of the information presented in the FOSSisms article. The FOSSisms article is about sixteen basic principles that should be held by students involved in open source projects. Many of these FOSSisms, including but not limited to numbers 5, 7, 8, and 11, stuck out to me as being peculiar but important for me as not only as a future software developer, but as a student working on an open source project. 

I especially found the “FOSSism #8: Branches are free” FOSSism novel, because my conception of branching was a lot more strict instead of experimental. It has given me a bit of a different outlook for development and experimentation.

Links:

https://opensource.com/education/14/6/16-foss-principles-for-educators

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

Christian Shadis

Worcester State University’s pantry, Thea’s Pantry, is a member in the Libre Food Pantry Community Humanitarian Free and Open-Source Software (HFOSS) project. To prepare to contribute to this project, I familiarized myself with the project’s documentation. Of note was the project’s workflow process, which resolved several questions I previously had about large-scale projects and version control. I had wondered whether many small commits would overload the repository, or whether professional developers were expected to commit much less frequently than I was used to. In the Thea’s Pantry workflow, small inconsequential commits are ‘squashed’ when a feature is merged into the main branch of the repository. I had questioned the consistency of semantic versioning, but Conventional Commits and the automated semantic-release tool¹ addressed those concerns. Examining the documentation offered me some extra insight into how smaller projects become larger, distributed ones.

¹https://github.com/semantic-release/semantic-release

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

One line that I found interesting was “Being respectful of differing opinions, viewpoints, and experiences” under the Code of Conduct. I agree with this statement, and what I find interesting about this line is the fact that when we write something on the internet, sometimes what we write might be misconstrued or misinterpreted by others. I think this is partly because it is difficult to detect the tone something is written on the internet. So, we may end up offending someone even if we do not mean to. One such example is sarcasm. Sarcasm is hard to detect online so even if we did not mean to be disrespectful, it may come off that way. So, I think it’s something people should keep in mind when posting something on GitLab or Discord. I chose this topic because I like satire and dark humor, so I use sarcasm a lot online.

https://librefoodpantry.org/docs/code-of-conduct

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Christian Shadis

I will be spending my final semester at Worcester State University contributing to the LibreFoodPantry Humanitarian Free and Open-Source Software (HFOSS)¹ project. In reviewing the mission statement, values, and other biographical sections of their website, I was directed to a list of Heidi Ellis’ sixteen ‘FOSSisms’², advice primarily for developers new to open-source projects. There was a recurrent theme among some FOSSisms – a developer should contribute as much as they can, regardless of the size of the fix they provide, or how perfect the code is. Version control allows for easily fixing mistakes, and creating new branches allows for editing code without affecting the main branch. I have been a perfectionist throughout my college career, so I found that perspective both surprising and helpful. I plan to apply these (and the rest of the) FOSSisms in these coming months.

¹https://librefoodpantry.org/
²https://opensource.com/education/14/6/16-foss-principles-for-educators

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.