Team Data
Team Members: Luis Flores Lozano, Cesar Perez, Austin Connick, Travis Myers, Raul Manquero-Ochoa
Spokesperson: Cesar Perez
Member Skills:
Luis Flores Lozano
Database, SQL, communication, Python, IT
Cesar Perez
Python, Java, HTML, Word, Excel, Power Point
Austin Connick
Java, Python, C
Travis Myers
Python, JS, Linux, R, SQL, excel
Raul Manquero-Ochoa
Basic R, Python, MS Office, Basic Kali Linux
GitHub Site: https://shadoweyes75.github.io/MLCAS2021/
GitHub link: https://github.com/Shadoweyes75/MLCAS2021
10 Rules:
Rule 1: Develop reflexive habits
While we did end up making use of this rule, we never really leaned into it as much as we should have. We made use of a lot of the other team's scripts and resources but looking back we acknowledge that we should have made more of an effort to reach out to the other groups to fill in the gaps in our abilities. We had ample opportunity to do so with all online communication being done through slack, and we were even given time in class to talk with the other groups. Often times it felt like we were too focused on trying to find solutions to our problems that we didn't really think to ask for help.
Rule 2: Communicate the project management plan early and often
We think we did a pretty good job at communicating our progress to one another. Every class we worked on the midterm in ended with a recap of where we were and what our priorities moving forward were. Though looking back, our lack of understanding data and models made it difficult to set clear milestone goals since we weren't really sure what clean and processed data, or a working model looked like. It also became very clear early on that we severely underestimated how long it would take us to accomplish certain tasks, making a clear timeline for the project increasingly hard to maintain.
Rule 3: Speak the same language
This was a very important rule for us looking back on this project. Seeing as our team lacked experience in many of the aspects of this project, a lot of our time was spent looking things up and making sure that when we brought it up to the group, we were all on the same page as far as terminology, logic, and standard practices were concerned. Though we think that since all of us were on similar levels of experience at the start of this project, it took some of the pressure off when asking questions within the group. This also made it very easy to sympathies when someone encountered a problem that was giving them a lot of trouble or when someone made progress for the project as a whole.
Rule 4: Design the project so that everybody benefits
This was a hard rule to stick to, since many of us ended up coming from similar backgrounds and having similar strengths, many of us ended up having to work on aspects of the project that we didn't have much and/or any experience in. This caused obvious frustration when we kept encountering issues, though it also encouraged us to be constantly involved in what the other members of the group where doing.
Rule 5: Fail early and often
We had no problems with this rule. Very early we encountered a number of problems, both conceptual and technical. Whilst frustrating we each tried to keep the group in high spirits and encouraged each other to learn from what was going on. We also frequently spoke about the issues that we were having and whenever a solution was found it was communicated to the rest of the team.
Rule 6: Share collaboration tools
Our team was really good at sharing any sort of resources we came upon. After our meetings with Emmanuel the members present would talk to the rest of the team to get them up to speed, as well as share the websites and tools that they had been told to look into. Similarly whenever someone made progress in data visualizations, charts, graphs, and results were all shared in our group chat. It was very important to us that everyone knew what we were working with, so whenever someone had time to work on the project they would know what to research so that it could make sense.
Rule 7: Manage your data like the collaboration depends on it
Our team began with this mentality, knowing that it would be very important to understand the data. Though in retrospect we may have put too much effort into understanding the data, since it ended up causing problems later on. We think that this project really exemplified why managing data is extremely important to a project's success. Seeing how understanding the shape of the data and how to process it was crucial when it came to training the model. Our team also had issues with corrupted data files, this caused much confusion, though we learned that it's important to always double check the integrity of our data as well.
Rule 8: Write code that others can use and reproduce
Our team acknowledges how important it is to write code that can be reproduced, as this makes it easier for others to use and learn from what we produce. Though as the deadline came closer and closer we came to the agreement that being able to produce a working model should take priority over ensuring that our code would be lasting and reproducible. There was talk about looking into containers in order to ensure that our code would run regardless of updates to software, but we didn't end up having time for that.
Rule 9: Observe ethical hygiene
While we aren't knowledgeable of ethical guidelines, each of us were extremely sympathetic to the unique situations that each of us were in. We made a point of being transparent with our schedules and attempted to keep up moral throughout the whole project. We also added a license to our model, keeping true to convention of keeping our work legally safe.
Rule 10: Document your collaboration
While we held to this rule withing our group, there's very little in the way of documentation publicly when it comes to our progress throughout the project. Every time we had made progress/failed/added something to the project that was worth noting, we would post it on our discord group chat (our primary form of communication). This made it so that we all would be notified whenever someone added something meaningful to the project, with the cavate being that once we began to put our GitHub repo together, it would not accurately reflect our process throughout the project as a whole.
Ranking:
