Lunatic Labs Policies and Procedures

Students at Lunatic Labs will learn fundamental programming concepts, version control, Agile methodologies, documentation management, and software development best practices. By the end of the course, students will be proficient in:

Writing clean, maintainable code.
Collaborating using GitHub.
Managing projects in an Agile workflow.
Conducting and receiving code reviews.
Implementing automated testing.

The Leader’s Step-by-Step Guide

Understand and prepare the objectives, clients’ expectations, and timeline
Assess the individual's skill to assign responsibilities
Set up Jira and GitHub for the team
Conduct the first team meeting
- Project expectations and outcomes
- Provide tools for learning, such as online Github training or programming language quick courses.
- Share existing documentation or create a new one.
- Begin a sprint and create tasks (ensure tasks are not so big that they are not completed by the end of the sprint)
- A team leader should be able to ensure that everyone feels comfortable in their skills and the jobs they can do.

The Developer’s Step-by-Step Guide

Review the project’s goals and expected outcomes as explained by the team leader.
- Ask questions during the first meeting if anything is unclear.
- Learn about your responsibilities
- Clarify your tasks with the team leader if needed.
- Install and set up tools like GitHub, Jira, and any programming environment.
- Clone the project repository from GitHub and familiarize yourself with the code structure.

The Start of the Project

To get up to speed, you can use the provided learning resources (e.g., GitHub training and programming language tutorials).
- Focus on the project's tools and languages, such as C++, Python, or Docker.
- Learn how to create branches, commit changes, and open pull requests on GitHub.
- Understand basic Git commands like git pull, git commit, and git push.

Working on Tasks

Look for tasks assigned to you in Jira.
- If a task seems too large or complex, discuss it with your team leader to break it into smaller steps.
- Focus on completing one small piece at a time, such as fixing a bug or creating a single function.

Collaborate with the Team

Ask for Help:
- If you’re stuck, ask for guidance from a senior team member or your leader.
- Use Slack, team meetings, or code reviews to seek clarification.
- Submit your work for review and learn from feedback.
- Review others’ code if you feel confident; it’s a great way to learn best practices.
Communication:
- Update the Jira board to reflect your progress (e.g., move tasks from “In Progress” to “Done”).
- Before submitting your work, test it thoroughly to ensure it works as expected.
- Write clear and descriptive commit messages that explain what you’ve done
- Push your changes to the correct branch and open a pull request.
  - Ensure your pull request includes a description of what you’ve done and any testing performed.
Reflection:
- Share what you learned, what you found challenging, and suggestions for improvement during sprint retrospectives.
- Apply feedback from code reviews and retrospectives to grow your skills
- Prioritize tasks to ensure they’re completed within the sprint timeline.
- Maintain notes on what you’ve worked on and any issues you faced for future reference.
- Volunteer for tasks when you’re done with your assigned work.
- Offer help if you notice others struggling with their tasks.

Communication expectations

All team members must promptly and professionally communicate issues, questions, and announcements through Slack, Jira, GitHub logs, and emails.

Slack

During work hours (class time and/or team meetings), respond within 10-15 minutes whenever possible.
Outside of work hours (on or off campus during the week), responses should not exceed 30-45 minutes, unless occupied with class, extracurriculars, or studying.
If unable to respond immediately, send a brief message indicating your delay.
Off-site or commuting members should follow the same response time as on-site members outside work hours.
On off days (weekends, holidays, and/or inclement weather), response times may be longer, but direct @ mentions require prompt attention.

Jira

Move tasks from “To Do” → “In Progress” when starting.
When ready for review, move to “In Review” and request feedback from a teammate.
After approval, move to “Done”.

GitHub Logs

Document changes with clear and descriptive commit messages explaining what, how, and why the update was made.
Be specific about what you changed in the repo, and also explain how and why you changed or created a feature and fixed a bug. An example photo from GitHub is placed below:

This can be done in multiple ways, one of these being to commit comments.

Emails

Check emails at least once or twice daily, including on weekends.
Professors and teammates may need urgent responses.

Roles & Expectations

The roles in Lunatic Labs include Junior Developer, Software Developer I/II, Lead Software Developer, Software Project Manager, and Software Architect.

Students who are employed in Lunatic Labs can go up the hierarchy and get promoted through software studio courses listed in the following order:

SENG 3233 (Software Studio I)
SENG 3243 (Software Studio II)
SENG 4233 (Software Studio III)
SENG 4243 (Software Studio IV)

Junior Developer

Someone who is enrolled in SENG 3233 (Software Studio I).
Junior developers will gain introductory experience in various application domains, tool stacks, and platforms.
They typically have the least experience in Software Studio, and it would usually be their first time working with Lunatic Labs.
Each week, they will be assigned at least one task by their Team leader to accomplish.
Typical Tasks include:
- Figma and Wireframe for prototype design
- Basic user interface design & frontend development
- Assisting Developer Is and IIs
- Basic programming

Developer I

Someone who is enrolled in SENG 3243 (Software Studio II).
Each week, they will be assigned at least one task by their Team leader to accomplish.
They typically gain more programming and software knowledge than Junior Developers, making them more equipped to take on more responsibility.
Typical Tasks include:
- Figma and Wireframe for prototype design
- User interface design & frontend development
- Software testing and refactoring
- Backend development
- Assist in software architecture and infrastructure

Developer II

Someone who is enrolled in SENG 4233 (Software Studio III).
Developers II typically build off of the same skills as Developer I, but they have more experience and skill expertise in specific areas of software development.
Their team leader assigns them at least one task each week.
Typical Tasks include:
- UI/UX design
- Frontend development
- Backend development
- Software architecture & design
- Software construction
- Designing verification and validation approaches
- Additional responsibilities from a project management perspective

Lead Software Developer

A potential path for a student enrolled in SENG 4243 (Software Studio IV).
Lead Software developers lead the developers I and II toward the completion of their projects.
They’re an all-rounder: both leading the charge on their project via Jira and working on the project themselves.
They continue to build on skills developed in previous projects, and they can now design and evaluate various Architecture and Design approaches.
Typical Tasks include:
- Planning sprints
- Hosts code reviews, sprint reviews, sprint retrospectives, and client meetings.
- Software automated testing
- Frontend development, backend development, system design, or all three
- Handling documentation and frameworks
- Testing and deployment of software
- Assigning tasks to members/filling the Jira backlog board
- Maintaining the Jira board
- Reviewing and approving teammates’ Software Construction
- Implementing verification and validation approaches, including Continuous Integration and Delivery frameworks
- Responsibilities from a project management perspective

Software Project Manager

A potential path for a student enrolled in SENG 4243 (Software Studio IV).
Software project managers lead the development of Is and IIs toward the completion of their project, and they typically work on the Jira/Kanban board and backlog.
They have less actual software development work than other software developers and architects
Typical Tasks include:
- Managing project timelines, resources, and team coordination
- Assigning tasks to members/filling the Jira backlog board
- Knowing how to implement Agile, Scrum, or other development methodologies
- Assisting in starting and closing the sprint.
- Responsibilities from a project management perspective

Before taking Software Studio I, students are required to take an introductory class called Intro to Software Engineering (SENG 2513). This is because before you start to become a junior developer, you need a basic understanding of:

Software development life cycle
- Approaches to documentation
- Project management
- Software testing and verification
- Industry-standard tools that support software.

Starting a Jira setup

1. Purpose

This SOP aims to outline the procedures for setting up Jira, which ensures efficient project management, issue tracking, task organization, collaboration, and customization of workflows.

This platform is important for all software developers to create their projects.

2. Procedure

Go to https://www.atlassian.com/software/
Sign in using your school email address and set up your account
Verify your email address and set up your account with a password and any required profile details.
Once signed in, you will be taken to your Atlassian dashboard.
Click on the Jira Software option among the available products.
Click on the Create Project button.
Select a project template - Scrum and provide a meaningful project name!
Once your project is created, invite members by entering their email addresses.
Familiarize yourself with the board layout. Common columns include Backlog, In Progress, Review, and Done.

Time Management

1. Purpose

Time management aims to establish clear guidelines for time management, tracking, and accountability at Lunatic Labs.

Proper time management ensures efficient project execution, workload distribution, and value-driven contributions to the team.

2. Scope

This SOP applies to all team members at Lunatic Labs, including those enrolled in single or multiple software studio courses.

Time management at Lunatic Labs includes logging in hours, using time effectively and productively, and managing that time throughout the weekly sprint.

3. Responsibilities

All Team Members: Log time accurately, manage workload effectively, and contribute meaningfully to the project. They are required to log the time they spend working on deliverables such as user stories, bugs, features, improvements, and other project-related tasks.
Project Leads & Managers: Monitor time logs, ensure balanced workload distribution, and provide support on time allocation.
Instructors & Supervisors: Evaluate contributions based on impact rather than hours worked.

4. Workload Requirements

Each employee working at Lunatic Labs must be able to work about 7 hours every week
- A total of 98 to 105 hours by the end of the semester.
Those taking two software studios must contribute about 14 hours a week
- A total of 196 to 210 hours by the end of the semester.
Their work will be measured and evaluated based on its value contribution to the project, not on “effort/time spent”.
Developers should avoid overcommitting to a single deliverable that they have spent a long time on and have not made much valuable progress on.
Furthermore, making sure the amount of time spent on a project and meeting the hour requirements should not be the only priority.
The time spent should equate to the value of productivity, and the contribution you are giving is important.

5. Weekly Time Management

Mandatory “company meetings” will occur during the normal meeting times of the primary section of the course.
Team members will also need to make time throughout the week, from the beginning to the end of the sprint, to make their contributions.
If it’s either working in small groups or individually, the time spent should count and be logged.
While most developers will work exclusively on a single project, some developers will be required to “split” their time between multiple projects, but most will be “full time” on a single project.
Time allocations should be documented for each project.

Logging Time on Jira

Go to Apps -> Timesheet
Go to Calendar
Open the Relevant Issue
- Navigate to the specific issue for which you want to log time.
- Click on the issue to view its details.
Locate the Time Tracking Section
- On the issue page, look for the "Work Log" section. This is usually found on the right-hand side or within the issue details, depending on your Jira layout.
Initiate the Log Work Process
- Click the "Log Work" button or the “+” button on the day you have worked.
Enter Time Spent
- Time Spent: In the pop-up or form that appears, enter the amount of time you spent on the task.
- Example formats include “2h 30m”, “1d”, or “45m”.
- Date Started: Confirm or adjust the start date/time if necessary.
Save Your Work Log
- Once you’ve filled in the necessary details, click "Save" or "Log" to record your time entry.
- Your logged time should now appear in the issue’s work log or time-tracking section.
Review Your Logged Time
- Verify that the logged time is correctly reflected in the issue details.
- Each employee working at Lunatic Labs must be able to work about 7 hours every week.

Sprint Planning

1. Purpose

Sprint planning aims to ensure that the development team is aligned on the work to be completed during an upcoming sprint. This meeting sets clear priorities, assigns tasks, and defines achievable goals within a set timeframe.

The key objectives include:

Defining the sprint goal based on project priorities.
Breaking down user stories into manageable tasks.
Estimating task complexity using story points.
Assigning tasks to team members.
Ensuring that the workload is realistic and achievable within the sprint duration.

2. Scope

This process applies to all development teams following an Agile workflow and includes:

Identifying and prioritizing user stories or tasks from the backlog.
Refining tasks to ensure clarity and feasibility.
Assigning story points to estimate effort.
Distributing work evenly among team members.
Tracking sprint progress using tools like Jira, Trello, or GitHub Projects.

This SOP ensures that sprint planning is structured and results in a clear, actionable plan, improving productivity and collaboration.

3. Procedure

Here are the specific steps involved in planning a sprint for each week:

Add new User Stories or Tasks to your Backlog and give them Story Points.
Go to your project’s Jira board.
Go to the backlog of the Jira board.d
Click the “create issue” button on either your current sprint or your backlog to create a new issue, and then click on that new issue or click on an already existing issue.
Scroll down until you see “Story Point Estimate” under “Details”. Besides, it should say “none”.
Click on it to enter the number of story points you think the issue should be worth.
- Story Points should follow the Fibonacci sequence (1, 2, 3, 5. Any higher, and the issue will be split into smaller ones.
If a user story cannot be completed within one week, break it into smaller, manageable tasks.
Prioritize the issues in your Backlog. What’s most important to work on next?
- Review all issues and determine which are most important to work on next.
- Rank tasks based on importance.
Assign Tasks to Team Members
- Ensure each team member is assigned at least one issue they commit to completing during the sprint.
- Tasks should be small and clear enough to guarantee completion within the sprint.
Tasks may include learning activities (ex., completing a tutorial or experimenting in a sandbox environment) to better understand the tools, language, or code base.
- After completing the learning activity, it is suggested that you implement what you learned into future code for your projects.
Begin the Sprint
- Once all tasks are assigned and prioritized, officially start the new sprint.
- Use Jira to track progress throughout the week.

Sprint Retrospective

1. Purpose

The Sprint Retrospective meeting should occur after the Sprint Review is completed and before the next sprint begins.

2. Scope

This procedure applies to all development teams within Lunatic Labs who follow an Agile or Scrum-based workflow. Participation is mandatory for:

Team Leads, who facilitate the retrospective session.
All Team Members must actively contribute to the discussion and feedback process.

3. Responsibilities

The process applies to all development teams, involving:

Team Lead
- Conducts the retrospective meeting
- Discusses takeaways from the previous sprint
- Opening discussions for improvements for the next sprint
Team Members
- Participate openly and respectfully
- Provide feedback regarding the past sprint
- Collaborate on identifying improvements

4. Procedure

4.1 Timing
Usually, start the sprint retrospective after taking a screenshot of the Jira board and right before starting the next sprint.

4.2 Discussion
Typically, the team lead asks and all team members answer three questions:

What work has been done well in this sprint?
What work hasn’t been done well?
What should we start doing to improve?

4.3 Collaboration and Feedback

Team members respond to each question in turn, either verbally or through shared collaborative tools (e.g., Jira, Google Docs).
Feedback should focus on both individual and team-level insights.

4.4 Action Steps

Identify specific improvements based on feedback from the discussion
Write down tasks for implementation in the next sprint.
Review any previous sprint’s retrospective outcomes to track progress.

GitHub Version Control

1. Purpose

This Standard Operating Procedure (SOP) defines the GitHub workflow for managing version control, code collaboration, and repository best practices.

It ensures that all developers follow a standardized process for maintaining project integrity, tracking changes, and collaborating efficiently.

2. Scope

This SOP applies to all team members contributing to a project via GitHub. It includes guidelines on repository management, branching strategies, pull requests, code reviews, and issue tracking.

3. Responsibilities

Team Members & Developers:
- Follow the GitHub workflow, including branching and pull request procedures.
- Regularly update their branches and resolve conflicts when necessary.
- Keep commitments meaningful and follow best practices for documentation.
Reviewers:
- Conduct thorough code reviews before merging changes.
- Ensure adherence to coding standards and project requirements.
Project Maintainers & Leads:
- Manage the repository structure, enforce workflow standards, and oversee merging strategies.
- Maintain documentation and ensure version control policies are followed.

4. Procedure

4.1 Setting Up GitHub Access

Create a GitHub Account:
- Sign up at https://github.com if you don’t already have an account.
Request Repository Access:
- The team lead or repository owner must invite new contributors.
Configure Git Locally:
- Set up Git on your system:
  git config-- global user. name "Your Name"
  git config-- global user.email "your-email@example.com"
Clone the Repository:
- Navigate to the repository and copy the clone URL.
- Run the following command: git clone [repository URL]

4.2 Branching Strategy

Main Branches:
- Main: Production-ready code (no direct commits allowed).
- Develop: Active development, where feature branches are merged.
Feature Branches:
- Naming convention: feature/[short-description]
- Example:
  git checkout -b feature/login-authentication

4.3 Committing and Pushing Changes

Check Out a Branch:
git checkout -b feature/new-feature
Make Changes and Stage Them:
git add.
Write a Meaningful Commit Message:
git commit -m "[Feature] Login success"
Push to Remote Repository:
git push origin feature/new-feature

4.4 Work in Progress Commit

For a work-in-progress commit, here are the steps to follow for the command line, either in your bash terminal or in your VSCode terminal:

Stage your changes: git add.
Put in a message to describe your commit:
git commit -m “[descriptive message]”
Push to remote branch (optional): git push origin <branch-name>

After committing the feature, you should reset the branch if needed:

git fetch origin main: fetches the latest changes and most recent updates from the remote main branch.
- git reset –soft origin/main: This resets your feature branch to match the latest commit from the remote main branch but preserves all your local changes in the staging/uncommitted area.

If you don’t want temporary commits cluttering your history, use git stash and git stash pop to restore your work later.

To do a work-in-progress commit in GitHub, follow these steps:

Go to the page of the repository you're working on.
Click on the file you want to edit, or click the "Add file" button.
Click on the pencil icon in the upper right corner to edit it and make the necessary changes.
Scroll down to the "Commit changes" section.
In the "Commit message" box, enter your descriptive message about your progress.
Select "Commit directly to the main branch" or "Create a new branch for this commit and start a pull request".
Click “Commit changes”

4.5 Creating a Pull Request (PR)

After committing, you should push your committed changes to the remote repository: git push origin “branch-name.”

Here are the steps:

Navigate to the GitHub repository.
Click "New Pull Request" and select the correct branches.
Add a descriptive title and detailed description of your changes.
Assign reviewers and request feedback.
Submit the PR and wait for approval.

To fetch the latest changes from the remote repository and merge them into your current local branch (the master branch), you would type git pull or git pull origin main in the command line.

4.6 Code Review & Approval

Reviewers must check:
- Code readability and adherence to project standards.
- Functionality and potential bugs.
- Performance and security best practices.
Approval Process:
- Leave comments for required changes.
- If everything looks good, approve and merge the PR.

4.7 Merging & Resolving Conflicts

Update Local Branch:
git pull origin develop

Resolve Conflicts:

Open conflicting files and manually resolve differences.

Push Resolved Changes:
git add .
git push origin feature/new-feature-- force
Merge PR and Delete Branch:
- Once approved, merge the branch via GitHub.
- Delete the branch locally and remotely:
  
  git branch -d feature/new-feature
  
  git push origin-- delete feature/new-feature

4.8 Keeping the Repository Clean

Delete old and merged branches regularly.

4.9 Issue Tracking & Collaboration

GitHub Issues:
- Create new issues for bugs, tasks, or feature requests.
- Assign team members and add relevant labels.
Document Discussions in Issues & PRs:
- Keep project updates and decisions documented for future reference.

5. References

5.1 GitHub Commands

Setup & Init

git init - Initialize an existing directory as a Git repository.
git clone [url] - retrieve an entire repository from a hosted location via URL.

Stage and Snapshot

git status - show modified files in the working directory, staged for your next commit.
git add [file] - add a file as it looks now to your next commit(stage).
git reset [file] - unstage a file while retaining the changes in the working directory.
git diff - diff of what is changed but not staged.
git diff-- staged - diff of what is staged but not yet committed.
git commit -m "[descriptive message]" - commit your staged content as a new commit snapshot.
git push - uploads changes and commits from the local repository to the remote repository
git pop - moves shelved changes into their working directory
git stash - saves and preserves changes without committing them yet

Branch & Merge

git branch - list your branches, an * will appear next to the currently active branch.
git branch [branch-name] - create a new branch at the current commit.
git checkout -b [branch-name] - create a new branch based on the current HEAD, git checkout or git switch [branch-name] - switch to another branch and check it out in your working directory.
git merge [branch] - merge the specified branch's history into the current one.
git log - show all commits in the current branch's history.
git pull - fetch the latest changes from the remote repository and merge them into your current local branch (the master branch)
git fetch - fetches the latest changes and most recent updates from a remote repository, but does not merge into your current local branch.
git rebase or git pull —rebase - rewrites and tidies your branch history, using the current HEAD commit of the base branch as its base

6. Review & Revision

This SOP will be reviewed every semester to ensure alignment with best practices and project requirements. Any updates should be added before each semester so that every new team or student can easily follow the steps.

Code Review Process

1. Purpose

Code reviews aim to ensure code quality, maintainability, and adherence to best practices. Code reviews help identify potential bugs, improve readability, and foster collaboration among team members. The key objectives include:

Ensuring consistency with coding standards and best practices.
Identifying and resolving potential bugs or security vulnerabilities.
Enhancing code readability and maintainability.
Facilitating knowledge sharing among developers.
Preventing technical debt by enforcing clean and efficient code.

2. Scope

This SOP ensures that all team members have the tools and knowledge to use GitHub efficiently, maintaining a smooth and structured development process.

This process applies to all code changes that require integration into the main codebase. It includes:

Reviewing pull requests before merging.
Checking adherence to project coding standards.
Assessing the impact of changes on existing functionality.
Providing constructive feedback to developers.
Running automated tests to validate changes.

3. Responsibilities

Developers:

Prepare code for review
Create pull requests
Respond to feedback and comments
Update PRs as needed.

Reviewers:

Conduct thorough reviews
Provide constructive feedback
Approve or request changes.

Team Leads:

Ensure compliance with the SOP
Facilitate communication
Monitor the code review process for continuous improvement.

4. Procedure

4.1 Prepare Your Code for Review

Push Your Changes:
Commit your changes to your branch and push them to the remote repository.
- use git push on your remote terminal to push onto GitHub
Create a Pull Request (PR):
Open a PR with a clear title and a detailed description that explains what changes have been made and the rationale behind them.
Click Create Pull Request Button

Example of what a Pull Request page should look like

4.2 Assign Reviewers

Select Reviewers:
Assign team members who are knowledgeable about the affected modules or features.

Example of assigning reviewers

Example of Selected Reviewers
Notify the Team:
Ensure that reviewers are promptly informed via the appropriate communication channels (e.g., Slack, email).

4.3 Review the Code

Examine the Diff:
Review the changes line by line using your code review tool (e.g., GitHub, GitLab, Bitbucket).

Go to Files Changed tab to see all changes made

Example of examining changes (green is for the new updated lines of code and red is for the deleted lines of code)
Evaluate Quality:
- Ensure adherence to coding standards and best practices.
- Check that the code is clean, well-documented, and easy to understand.
Assess Functionality:
Confirm that the code meets the functional requirements and integrates seamlessly with the existing codebase.

4.4 Run Tests

Automated Testing:
Verify that all automated tests pass within the CI/CD pipeline:
CI/CD stands for Continuous Integration and Continuous Deployment (or Continuous Delivery). It’s a modern software development practice that helps teams release code faster, more reliably, and with fewer bugs.
Developers push code to a shared GitHub repository.
Every time code is pushed or a pull request is made, automated tests run
If tests pass, the code is considered safe to merge

Benefits:

Detects bugs early.
Keeps the codebase stable.
Encourages smaller, frequent commits.
After CI steps are successful, CD pipelines can automatically deploy code to staging or production servers. This can include updating a website, releasing a mobile app version, or pushing backend updates.

Benefits:

Faster release cycles.
Less risk in deploying changes.
Better feedback from users.
Manual Testing:
If applicable, perform manual tests to validate the new or modified functionality.

4.5 Provide Constructive Feedback

Comment Inline:
Leave clear, specific comments directly on the code for sections that require improvement.
Suggest Improvements:
Provide actionable recommendations or code examples where necessary.
Maintain a Positive Tone:
Balance critique with positive feedback to reinforce good practices.
Example of using inline comments

4.6 Developer Response

Address Feedback:
Respond to review comments, clarify doubts, and make necessary changes.
Update the PR:
Push updates to the branch and reassign the PR for further review.

4.7 Final Approval and Merging

Re-Review:
Once changes are made, reviewers re-assess the updated code.
Approve or Request Further Changes:
Approve the PR if all concerns are resolved or request additional modifications.
Merge Strategy:
Merge the code using the agreed strategy (e.g., merge commit, rebase, or squash) and close the PR.

4.8 Post-Merge Activities

Monitor Deployment:
Ensure that the build and deployment process is successful and that no issues arise from the merged code.
Reflect and Document:
Record lessons learned and update this SOP if necessary for continuous improvement.

5. Review and Revision

This SOP shall be reviewed annually or as needed to reflect changes in processes, tools, or team structures.

All updates must be documented in the revision history and approved by the designated authority.

Address Feedback:
Review the comments, ask questions for clarification if needed, and make necessary changes.

If everything functions well, reviewers can type “LGTM!”
Update the PR:
Push new commits to the branch to address the review comments.

6. Final Approval

Re-Review:
The reviewer(s) check the updated code to ensure that all concerns have been addressed.
Approve or Request Further Changes:
Approve the PR once satisfied or request additional modifications if necessary.

Approvals are indicated by the check mark

7. Merge the Code

Merge Strategy:
Use the defined merge method (e.g., merge commit, rebase, or squash) as per your team’s process.
- git merge [branch], git rebase or git pull —rebase, etc.
Close the PR:
Once merged, close the PR and update the main repository accordingly.

After approval, let supervisor know when to merge

Confirmation that a PR has been merged and closed

8. Post-Merge Activities

Monitor Deployment:
Keep an eye on the build or deployment process to catch any issues.
Reflect:
Document lessons learned during the review process for future improvements.

Client Meeting Step by Step

1. Purpose

The purpose of a client meeting is to establish clear communication between the development team and the client.

These meetings ensure that project objectives, requirements, and expectations are well understood, allowing for effective collaboration, timely feedback, and alignment on deliverables.

Gathering and clarifying project requirements.
Demonstrating progress and receiving feedback.
Addressing any challenges or concerns.
Aligning project goals with client expectations.
Ensuring transparency and fostering trust between both parties.

2. Scope

This process applies to all client-facing interactions, including:

Initial requirement-gathering meetings.
Progress update meetings (weekly/monthly check-ins).
Demo or milestone review meetings.
Issue resolution and feedback sessions.
Final project delivery discussions.

Before the Meeting:

Understand the client’s objectives and how your project aligns with them.
Review any materials or briefs shared by the client. Prepare any questions or topics you’re expected to address.
Ensure that your assigned tasks are ready for presentation, if applicable.
Rehearse your points in simple, clear language.
Check in with your teammates to align on what will be presented and avoid redundancy.

During the Meeting:

Maintain good posture, make eye contact, and smile (it helps with tension).
Write down key points, especially client requirements, deadlines, and feedback.
If you’re meeting the client for the first time, briefly introduce yourself and your role in the project.
If presenting, stick to what is relevant.
Clarify requirements or seek more information about unclear aspects of the project.
If a teammate forgets something or struggles to explain, provide help tactfully.

After the Meeting:

Summarize the key points discussed, including requirements, deadlines, and action items.
If you were assigned to take notes, distribute them to the team through Slack, email, or your project management tool.
Update Jira or your to-do list based on new requirements or feedback received during the meeting.
If something wasn’t clear during the meeting, ask your team lead or the client via email or Slack.
Begin or continue work on tasks discussed in the meeting. Prioritize any that the client emphasized.

Documentation Management

1. Purpose

The purpose of documentation management is to properly and efficiently capture, store, organize, and manage physical and digital documents within any organization you are in charge of or you are working for.

Many Document Management Software programs exist in Lunatic Labs.

2. Scope

According to The Association for Intelligent Information Management (AIIM), some of the key features in document management include:

Check-in/check-out and locking to coordinate the simultaneous editing of a document, so one person’s changes don’t overwrite another’s
Version control, so tabs can be kept on how the current document came to be and how it differs from the versions that came before (this can be done via Github)
Roll-back, or “activate” a prior version in case of an error or premature release (Again, this can be done via Github)
Audit trail to permit the reconstruction of who did what to a document during its life in the system (Can probably be done by GitHub or by the history tab in Google Docs)
Annotation and Stamps

For every relevant document (such as README files and our Standard Operating Procedures):

The primary version should be stored in the project’s GitHub repository.
A Backup Version should be maintained as an independent, synchronized copy.
Whenever the document in GitHub is updated, the backup must also be updated, and vice versa.
Keeping all copies digital reduces storage requirements and facilitates efficient version control and sharing.

This strategy ensures that all important documents are consistently maintained, traceable, and readily available, enhancing both collaboration and accountability across the team.

3. Types of Documents

3.1 Document Creation

Identify documentation needs (e.g., integration tests, software design, system tests).
Incorporate diagrams, flowcharts, or code snippets when necessary.
Maintain consistency in terminology and definitions across documents.

3.2 Integration Test Documentation

Define the scope and purpose of integration tests.
Document test cases, expected outcomes, and dependencies.
Include execution steps, sample data, and automation details.
Ensure all integration points and APIs are covered.
Provide error handling and troubleshooting guidance.

3.3 Software Design & Organization Documentation

Introduction and overview

There should be a strong introduction about the entire project and its design.
This should include a main summary, the Goals and scope of the project, and the primary features needed to make the project successful.
A README.md file in a project’s GitHub repository should show this.
A software project needs detailed database structures and data models to show how its system stores, manages, and processes its data and information
Examples: Data Flowcharts, Database structure and table layouts, andData validation and integrity rules

Interface design

This is used for how different components of a software system communicate with each other
This includes internal interfaces between modules and external interfaces for APIs or integration points.
Examples: API specifications and protocols, Message formats and data structures, Functions for handling errors and exceptions in code, and Security and authentication methods and protocols

Component design

There should be information provided about each individual module and component in a system
This includes what inputs and outputs are needed and their specific functionality
This documentation also needs to describe dependencies on other components or any external systems

Assumptions and dependencies

Assumptions are needed for the building and designing of a project.
Dependencies may impact the system’s implementation
Examples: Constraints for hardware, software, or infrastructure, Dependencies on external libraries or sources, and Technical assumptions of the development environment

Glossary of terms

Describe any terms that are important for a project, including:
Technical terms
Acronyms
Any technical jargon
This can be in a PDF file or a GitHub Markdown file in the repository

Miscellaneous

Describe the system architecture, frameworks, and libraries used.
Provide UML diagrams, entity-relationship models, or flowcharts.
Document design decisions and their rationale.
Define module interactions, dependencies, and APIs.
Ensure documentation aligns with coding standards and best practices.

3.4 System Test Documentation

Outline system-wide test scenarios and objectives.
Document system test cases, inputs, expected outputs, and acceptance criteria.
Provide environment setup instructions (OS, databases, configurations).
Include performance, security, and stress test documentation.
Maintain logs of test executions, results, and bug reports.

3.5 GitHub Repository Documentation

Ensure each repo has a README.md file with project details.
Provide contribution guidelines, coding standards, and branching strategy.
Document deployment procedures and CI/CD pipelines.
Include API references or configuration guides when applicable.

3.6 Owner’s Manual & User Guides

Provide clear step-by-step instructions for using the software/system.
Include screenshots, GIFs, or video demonstrations if necessary.
Document troubleshooting steps and FAQs.
Ensure accessibility by using simple language and structured formatting.

3.7 Visual Aids: Diagrams, Flowcharts, and Infographics

Explain complex processes using UML diagrams, ER diagrams, flowcharts, and wireframes.
Ensure that visuals are labeled clearly with legends where necessary.
Store diagrams in vector formats (SVG, PNG, PDF) for clarity.
Use tools like Lucidchart, Draw.io, PlantUML, or Visio.
Focus is on how users interact with the software project and its system
Details of layout, navigation, functionality, and specific design considerations.

UML Diagram from L.U.K.E.

3.8 Readability and Accessibility Best Practices

Use consistent formatting (headers, bullet points, tables)
Write concisely and structurally (avoid excessive jargon).
Include a glossary for technical terms.
Use table of contents and searchable formats (PDFs, HTML).

3.9 Version Control & Updates

Use version numbers (e.g., v1.0 for major releases, v1.1 for minor edits).
Maintain a Document Revision Log to track changes.
Schedule periodic document reviews (quarterly or bi-annually).
Archive outdated documents while keeping a retrievable record.

4. Design Documentation

Design Documentation will be different for every team because each team will be working on something different, with different scopes and end goals.

However, according to Atlassian, creating a design document can undergo these general steps:

4.1 Gather requirements and initial information.

Requirements and specifications
Input and feedback from stakeholders
Documentation
Constraints and limitations

4.2 Outline the system architecture.

Choosing diagrams appropriate for your project (design patterns, architectural systems, etc.)
Create an outline, including major components and subsystems

4.3 Detail the data design.

Design databases and relationship diagrams
Define data validation rules and integrity constraints
Outline where and how data will be stored
Consider scalability and performance

4.4 Specify the interface and component design.

Define individual components and interfaces
Define API specifications and protocols
Describe what each major component of the project does

4.5 Review and refine the document with stakeholders.

Share the document with team members and the team lead, then with the supervisor for review
Gather feedback, address concerns and suggestions, and update the design based on the feedback
Ensure everyone, including stakeholders, agrees before finalizing the document

Automated Testing Process

1. Purpose

The purpose of automated testing is to ensure software quality, efficiency, and reliability by reducing human error and speeding up the testing process.

2. Scope

This procedure applies to all software development team members and leaders who write, execute, and maintain automated test scripts for the organization's applications.

3. Procedure

3.1 Identify the requirements, objectives, and test scope

Define functional and non-functional requirements, performance benchmarks, and expected pass/success criteria.

3.2 Develop the test plan

Find the appropriate testing framework and tools
- Some examples are: Selenium, PyTest, JUnit, assert() in C++, Curl, and Wget in web pages, etc.
This depends on your programming language and the specific project needs.

3.3 Create test cases and scripts

Unit tests that provide as much code coverage as possible.
Provide tests meant to pass, fail, and meet edge cases.
Use a naming convention and standard format for test cases to ensure consistency, such as test_featureName_scenario.

3.4 Environment testing and setup before implementation

This could include web servers, hardware, OS, databases, and any machines, instruments, or third-party tools needed to perform the test.

3.5 Build, execute, and continue testing

Build, compile, and run your code
If compilation is successful, start building test cases and executing tests
Keep testing and ensuring you get the correct outcome every time.

3.6 Resolve/fix any mistakes

If output/results are incorrect, tweak your code
Create a Jira assignment and assign it to a developer to fix the code.
Conduct peer reviews
Place your tests throughout the project for debugging to ensure correct output and correct errors.

3.7 Analyze/review results

Generate reports on results if needed
Maintain test documentation to track progress

3.8 Maintenance

Define a maintenance plan for updating test cases as the application evolves.
Continue/repeat until all the tests output what you desire.

Deployment

1. Purpose

The purpose of deployment in software is to make it available to all users and other programs.

Typically, individual members of a project team will ensure that their code works and then push it to GitHub to integrate it with the rest of the software.

2. Scope

The team would then ensure that everything works together and iron out what doesn’t.

Once the code is built and complete, one member of the team will create a copy to publish on a server or a physical computer.

For example, the L.U.K.E. team deployed by zipping up the code used in the L.U.K.E. Kiosk, copying it to a flash drive, and then plugging that drive into the physical Kiosk to update it.

3. Procedure

Each member of a team should make a deployment checklist depending on their project’s guidelines.

The following is an example deployment checklist according to IBM:

The deployment checklist guides you through the following steps:

Specify the name, description, and categories to use for the deployment.
Selecting the software to be deployed.
Selecting the objective of the deployment.
Generating reports, identifying if SYSMODs are missing in the source software or any related instances:
SYSMODs typically refer to System Modifications**,** changes made to the base source code of internal software platforms. Any additional features or bug fixes, scripts, or changes not included in the vendor's standard release.
Avoid system failures due to overlooked modifications.
Specify the data set names, catalogs, volumes, mount points, and SMP/E zone names to use for the target software:
SMP/E (System Modification Program/Extended) is a software tool used on IBM mainframes to install and manage system software (like OS components or third-party products).

It allows administrators to:

Track what has been installed and where
Roll back changes safely if needed
Defining the settings to use for the deployment jobs and generating the jobs.
Submitting the deployment jobs and viewing the job output.
Specifying the name, description, and categories for the target software.

Lunatic Labs Teams

SkillBuilder/Rubricapp

GitHub: https://github.com/Lunatic-Labs/rubricapp
About: A web application for evaluating students' professional skills, such as teamwork and communication. The purpose of the SkillBuilder application is to allow instructors to assess teams of students in real-time using research-based or custom rubrics. Instructors can email students their results and download the data for analysis.
Materials Used:
- Frontend: JavaScript and React.js
- Backend: Python Flask, SQL Server
- Redis Server and Docker for running the frontend and backend

L.U.K.E.

GitHub: https://github.com/Lunatic-Labs/Kiosk
About: L.U.K.E. is a dynamic, multi-screen kiosk designed to inform and engage. From answering visitor questions to providing fun, interactive experiences, this cutting-edge system showcases the power of technology in enhancing campus navigation and exploration.
Materials Used:
Processing 4 to build the software
Java, used for all processing, libraries, scenes, and functions
A TV, connected to the computer via HDMI
A touchscreen, connected to the computer via USB
A web camera, connected to the computer via USB
A multi-outlet extension cord
A metal frame

Wind Tunnel

GitHub: https://github.com/Lunatic-Labs/Wind-Tunnel
About: Wind Tunnel provides researchers and students with intuitive, real-time visualizations of aerodynamic data from wind tunnel experiments. This software streamlines the data collection and analysis process, making interpreting and understanding experimental results easier.
Materials Used:
- Python for data visualization, testing interfaces, and user-friendly interfaces
- Direct integration with Keysight DAQ970A hardware

Pointless

GitHub: https://github.com/Lunatic-Labs/pointless-project
About: The point(less) of the Pointless Project is to create a compelling, puzzle-filled challenge inspired by the Synacor Challenge, but targeted at a pre-college audience. The goal is to allow the School of Computing (SoC) to engage potential students while selecting a college by providing opportunities to remain in contact, encourage curiosity, and engage in creative problem solving while learning about computing and the SoC.
Materials Used:
HTML/JavaScript/CSS for website organization and layout
C++ for the puzzle game programs

Ella’s House

GitHub: https://github.com/Lunatic-Labs/EllasHouse
About: Ella’s House is a text-based game application that showcases a pregnant college student navigating through life and surviving big events through adulthood and issues with motherhood.
Materials Used:
HTML/JavaScript for website organization and layout
C++ for the text-based puzzle game implementation

Technical Review

1. Purpose

The purpose of a technical review is to evaluate and validate the design, implementation, or architecture of a software feature.

It ensures that the solution is technically sound, meets project requirements, and aligns with team standards before further development or deployment.

Technical reviews help in catching issues early, improving design quality, and encouraging shared understanding among team members.

2. Scope

This process applies to any major component, feature, or architectural change that may impact system performance, maintainability, scalability, or integration with other parts of the project. It includes code walkthroughs, design document reviews, and pre-deployment validations.

3. Responsibilities

Presenters

Prepare a clear summary of the work being reviewed
Explain the purpose and context of the solution.
Walk through the design or code, highlighting key decisions and assumptions.
Identify known risks or limitations.
Give a demonstration of your work in action.
Provide supporting materials such as diagrams, test results, or documentation.
Be open to questions and feedback.

Audience

Evaluate logic, architecture, and design choices.
Ask questions about performance, scalability, maintainability, and security.
Look for consistency with coding standards and project guidelines.
Check if the solution aligns with user requirements and business logic.
Suggest improvements, ask for clarification where needed, and provide constructive feedback.
Verify that appropriate tests and documentation are planned or already in place.

Usage of AI

1. Purpose

Integrating AI into the development workflow is to enhance productivity and provide intelligent support for coding and documentation.

AI tools can assist developers in writing cleaner code, debugging faster, and generating relevant documentation and insights.

2. Scope

This section applies to all students and team members who use AI tools for development purposes. It includes AI-assisted code generation, documentation, project management automation, and other productivity tools.

3. Procedure:

Tools like GitHub Copilot, ChatGPT, or Tabnine can assist in writing functions, algorithms, and boilerplate code. They can also help interpret errors, suggest fixes, or recommend better practices.
Students should review AI-suggested code and ensure it aligns with project requirements and code standards.
If AI is used to assist with documentation or coding, put it in comments or commit messages. Do not take credit for code created by AI.
Avoid sharing sensitive or private project data with public AI tools.

Recommended Tools:

Copilot AI
ChatGPT
Deepseek
Claude

Additional Resources

GitHub Docs: https://docs.github.com/
Codecademy Git Course: https://www.codecademy.com/learn/learn-git
Clean Code Guidelines: https://github.com/clean-code-dev
Documentation Management & Guidelines:
Work In Progress Commit: https://digiden.dev/mastering-the-work-in-progress-wip-commit-strategy-in-git/RK=2/RS=6Zy6ivjX.pSq9zDxNRMzqPyKc1k
Pull Requests: https://blog.mergify.com/6-best-practices-to-review-pull-requests-in-github/

Name		Name	Last commit message	Last commit date
2023Draft.md		2023Draft.md
README.md		README.md

Uh oh!

Latest commit

History

Folders and files

Repository files navigation

Lunatic Labs Policies and Procedures

Getting Started

The Leader’s Step-by-Step Guide

The Developer’s Step-by-Step Guide

The Start of the Project

Working on Tasks

Collaborate with the Team

Communication expectations

Roles & Expectations

Junior Developer

Developer I

Developer II

Lead Software Developer

Software Project Manager

Starting a Jira setup

1. Purpose

2. Procedure

Time Management

1. Purpose

2. Scope

3. Responsibilities

4. Workload Requirements

5. Weekly Time Management

Logging Time on Jira

Sprint Planning

1. Purpose

2. Scope

3. Procedure

Sprint Retrospective

1. Purpose

2. Scope

3. Responsibilities

4. Procedure

GitHub Version Control

1. Purpose

2. Scope

3. Responsibilities

4. Procedure

5. References

6. Review & Revision

Code Review Process

1. Purpose

2. Scope

3. Responsibilities

4. Procedure

5. Review and Revision

6. Final Approval

7. Merge the Code

8. Post-Merge Activities

Client Meeting Step by Step

1. Purpose

2. Scope

Documentation Management

1. Purpose

2. Scope

3. Types of Documents

4. Design Documentation

Automated Testing Process

1. Purpose

2. Scope

3. Procedure

Deployment

1. Purpose

2. Scope

3. Procedure

Lunatic Labs Teams

SkillBuilder/Rubricapp

L.U.K.E.

Wind Tunnel

Pointless

Ella’s House

Technical Review

1. Purpose

2. Scope

3. Responsibilities