Feature Request: Projects Page for Vets Who Code

[jeromehardaway]

As Vets Who Code continues to expand, so do the number and variety of our projects. To better showcase our work and tell the story behind each initiative, we should create a Projects Page. This page will serve as a hub, listing all our projects in an engaging, organized manner, and linking to detailed pages for each project.

Proposed Features

•	Grid Layout: Use the same grid layout as the one implemented for our modules for consistency and visual appeal.
•	Project Cards: Each project should be represented by a card containing:
•	Project title
•	Brief description
•	Thumbnail or representative image
•	Detail Pages: Clicking on a project card should navigate users to a dedicated page with more information about the project, including:
•	Project overview
•	Technologies used
•	Team members or contributors
•	Implementation details and outcomes
•	Links to GitHub repositories or live demos

Goals

•	Provide a comprehensive overview of the projects we work on.
•	Help tell the story behind each project to better connect with the community.
•	Highlight the technical and creative implementations behind our work.

Next Steps

1.	Design a wireframe or mockup for the Projects Page.
2.	Adapt the existing grid layout used for modules to this page.
3.	Create a template for individual project detail pages.
4.	Populate the Projects Page with current Vets Who Code projects.

[jonulak]

🙋🏻‍♂️

[jeromehardaway]

@jonulak make a design doc for it first. Here is the template:

Feature Design Document Template

1. Feature Name

• Provide a clear and descriptive name for the feature.

---

2. Overview

• Problem Statement: What issue does this feature solve?
• Objective: What is the goal of this feature?
• Success Criteria: How will we know this feature is successful?

---

3. Stakeholders

• Who Needs to Know: List the people involved (e.g., teammates, testers, end-users).
• Who Approves It: Who will review and approve the design?

---

4. Scope

• What It Includes: Clearly list what this feature will do.
• What It Doesn’t Include: Specify what this feature will not do to avoid confusion.

---

5. User Stories

• Write clear user stories, such as:
  As a [user type], I want [feature or action] so that [value or benefit].

---

6. Visuals

• Add any sketches, diagrams, or wireframes that explain how the feature will look or work.

---

7. Technical Details

• Tools and Technologies: List the tools, programming languages, or frameworks needed.
• Data Requirements: Describe any database changes or new data needed.
• Connections: Does this feature rely on other parts of the system or APIs?

---

8. Risks and Assumptions

• Risks: What challenges might come up?
• Assumptions: What are you assuming about the system, users, or timeline?
• Mitigation Plan: How will you handle risks if they occur?

---

9. Testing Plan

• What to Test: List the key things to check (e.g., functionality, performance, security).
• How to Test: Briefly explain how these tests will be done.
• Success Criteria: Define what "success" looks like for this feature.

---

10. Rollout Plan

• Release Strategy: Will it be launched to all users at once or in stages?
• Monitoring: How will you track the feature’s performance after launch?

---

11. Maintenance

• Ownership: Who will maintain and improve this feature after launch?
• Handling Feedback: How will bugs or user feedback be addressed?

---

12. Timeline

• Break down the process into steps with rough deadlines, such as:
  • Finalize design
  • Start coding
  • Test the feature
  • Launch the feature

---

13. Sign-off

• Include the names or roles of the people who will review and approve this document.

[jonulak]

Feature Design Document Template Draft 1

1. Feature Name

• Vet Who Code App: Project Page

---

2. Overview

• Problem Statement: Outside of GitHub, we do not have a central location to showcase our projects. Non-technical users who are not familiar with GitHub may not be aware of our projects or how to view them.

• Objective: To create a hub to showcase our work in an engaging and organized manner

• Success Criteria:

---

3. Stakeholders

• Who Needs to Know: Teammates

• Who Approves It: Jerome Hardaway

---

4. Scope

What It Includes:

• The projects page will include a grid view of all of our current projects. Grid cards will include the project title, a short descrption, and a thumbnail showcasing the project.
• Clicking the project card will display a project detail modal view with an animation. The modal will contain the following information:
  • A project overview including a description and screenshots or other relevant images
  • Technologies utilized
  • Project organizers and top contributors
  • Implementation details and outcomes
  • Links to project deployments and github repos
  • Relevant GitHub statistics such as project stars, number of contributors, etc

What It Doesn’t Include:

• Project setup and technical details

---

5. User Stories

As a user visiting the site, I want to see projects that the organization has built. Seeing quality projects created by the organization makes me feel confident that this is an organization I want to join, donate, or contribute to.

---

6. Visuals

Project page wireframe

Project detail modal wireframe

---

7. Technical Details

• Tools and Technologies: Next, Framer Motion, TypeScript, Tailwind

• Data Requirements: Project summaries and screenshots, images, GitHub API data, troop testimonials

• Connections: Grid layout will be adapted from existing components in the modules page, relevant project statistics will be pulled using the github API

---

8. Risks and Assumptions

• Risks:

  • GitHub API rate limits might impact real-time data retrieval
  • Performance challenges with loading multiple project details

• Assumptions:

  • Module grid is trivial to adapt for project specific needs
  • GitHub API will remain stable and accessible

• Mitigation Plan:

  • Utilize static site generation with incremental static regeneration to limit API requests, allow fallback if GitHub API is not accessible, and maintain fast load speeds on the client side.

---

9. Testing Plan

• What to Test:

  • Page load times
  • Page functionality
  • API calls and responses

• How to Test:

  • Unit tests
  • Manual cross-device testing
  • Internal user acceptance testing

• Success Criteria:

  • All data loads & displays correctly
  • Page load time under 1 second
  • Smooth modal animations
  • Positive user feedback in internal testing

---

10. Rollout Plan

• Release Strategy: All at once

• Monitoring:

  • Error reporting
  • User feedback

---

11. Maintenance

• Ownership: Jon Onulak

• Handling Feedback:

  • GitHub issues will be created for problem feedback and assigned as necessary

---

12. Timeline

• Break down the process into steps with rough deadlines, such as:

  • Week 1: Design & wireframing

  • Weeks 2 & 3: Initial implementation

  • Week 4: Internal testing & bug fixes, Launch

---

13. Sign-off

• Jerome Hardaway

[jeromehardaway]

I have to say @jonulak I am loving this design document so far!