Hello All, today I decided to talk about FOSSisms 16 principles of open source software in teaching. On that that found interesting was number seven which was ask for forgiveness not permission. It basically said that should just start working on something and you don’t need to ask first. This is because changes you make have are unlikely to derail a project. This is because of the use of version control which means it is very easy for the community to undo what you did or even fix the mistake you made. I picked this a subject and this particular rule because it very different to how you typically work on group project where you should communicate and talk to other before you do anything

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

LibreFoodPantry is the project that my team and I will work on the whole semester for the CS-448 capstone class. This project is an open source base project we can contribute to this project and develop parts init and share it with two other Universities. we going to reflect our work on the WSU food … Continue reading LibreFoodPantry →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

For my CS capstone’s setup task 5, I have decided to write about my thoughts on the Principles of the Agile Manifesto linked to in the values section of the about page for LibreFoodPantry. Like the name suggests, the Agile Manifesto keeps you on your toes. Developers must be ready and able to respond to any necessary changes that may arise. The manifesto also requires regular communication. I really like how the principles of the manifesto promote living, evolving projects that adapt to situations as needed. I can see how following these principles will greatly assist in project development and achieving all the project goals. I look forward to adopting these principles and experiencing a project that abides by them.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Looking at the FOSSism link, one FOSSism I related to and liked was FOSSism #2: Be productively lost. Being that the project is open sourced, joining in may be confusing because you may not know what is going on at the time or what the scope is for development. I can relate to this being a CS major. Sometimes learning new things can be quite confusing especially when you start using code that is pre written and has framework available for you to utilize. While that can be convenient it can be bothersome if you don’t yet understand how that code works and perhaps you have different ideas on accomplishing the same thing. This FOSSism is all about embracing that confusion and worry, the open source environment invites new user and it a friendly environment to ask and learn from others.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Of the items linked to on the librefoodpantry.org home page, I found the section on Issue Trackers on the Communication page to be the most interesting. The LibreFoodPantry project allows developers to communicate with each other using the GitLab’s issue tracker. Developers can report bugs, request new features, and ask questions by creating a new issue either within a specific project or in the community section. This will notify other developers and allow them to communicate with each other to find a solution to the issue. I have never used this feature of GitLab, and I think it seems like a fantastic resource as it allows developers to collaborate with each other to find solutions to issues and make new plans. I chose to write about it because I think it could be useful for my classmates and I to use if we come across issues while working on the project.  

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

The LibreFoodPantry website has a description of the project and is professional, complete with a vision, mission, values, and license.

The most useful and interesting link on the website is the Principles behind the Agile Manifesto. This is clearly the work of software developers who were fed up with time-consuming processes and being locked in to a specific process or tool.

Working software is the primary measure of progress.

Principles behind the Agile Manifesto

Change is inevitable in software, and the most important thing is that it works. That is important to remember going into this field, and I hope writing about it solidifies the concept. It is tempting to set a plan and stick to it, as one does in most contexts.

This semester I am lucky to work with “motivated individuals” and hope to create great work with a “self-organizing team”.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

LibreFoodPantry has plenty of interesting information, but what got my attention was the Communication part. I think communication is very important for a team to succeed. Having so many options to communicate with each other, makes it so easy to solve problems that might come in our way. The issue tracker is a great solution to communicate and keep track of issues while working on the project. On the other hand, Discord and Google groups, get together not only students but mentors as well. Being a member of the LibreFoodPantry community gives us equal rights to communicate with each other using those tools. We all know that developing face to face is not always enough, and we all end up doing most of the work outside of class. We are lucky to have such useful communication tools that will make communication easier for us while working on this project.

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

I thought the issues section of the git lab project was really interesting and a great way to communicate with other members of the project on things that aren’t working to see if others are facing a similar problem or have a solution to it. I believe that it is a great way to give ideas to others and help generate interest in specific areas that are needed or could be created for the project. I really like that people can get involved and discuss ideas for future implementations and things that need to be done in order to move forward. The issues section is definitely a useful part of git lab that i have not used and seen used, but seeing it used in this way is good and helps me to understand how large groups efficiently use git lab to create and optimize projects.

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

For this first (technically second) post of this semester,  I decided to talk about the FOSSisms section of the LibreFoodPantry main page. This sections was located under the about section. This sections leads off with a short introduction about what FOSSisms are and it was very useful considering I have never seen the word used before. To put it simply, FOSSisms are maxims that Heidi Ellis developed from, open source culture. I won’t talk about all 16 of them because I would be here all day, but I will talk about some of my favorites. I really enjoyed the productively lost section because it explains that the students should get lost, but that they should use this sense of confusion to learn more about what they are confused about. The last section, I’ll talk about is avoiding uncommunicated work. This section was interesting because it basically says that all work should be communicated with other members of the group, and I think that is extremely important for this project that we are about to take on.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.