generated from nhcarrigan/template
This commit is contained in:
@@ -211,6 +211,52 @@ export const navigation = [
|
||||
label: "10. Graduation",
|
||||
link: "/mentorship/10-graduation",
|
||||
},
|
||||
{
|
||||
label: "Resources",
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
label: "Goal Setting Resources",
|
||||
link: "/mentorship/resources/goal-setting",
|
||||
},
|
||||
{
|
||||
label: "Project Planning Resources",
|
||||
link: "/mentorship/resources/project-planning",
|
||||
},
|
||||
{
|
||||
label: "User Story Resources",
|
||||
link: "/mentorship/resources/user-stories",
|
||||
},
|
||||
{
|
||||
label: "Technical Breakdown Resources",
|
||||
link: "/mentorship/resources/technical-breakdown",
|
||||
},
|
||||
{
|
||||
label: "Priority and Effort Resources",
|
||||
link: "/mentorship/resources/priority-effort",
|
||||
},
|
||||
{
|
||||
label: "Code Development Resources",
|
||||
link: "/mentorship/resources/code-development",
|
||||
},
|
||||
{
|
||||
label: "Code Review Checklist",
|
||||
link: "/mentorship/resources/code-review-checklist",
|
||||
},
|
||||
{
|
||||
label: "Final Polish Resources",
|
||||
link: "/mentorship/resources/final-polish",
|
||||
},
|
||||
{
|
||||
label: "Final Polish Checklist",
|
||||
link: "/mentorship/resources/final-polish-checklist",
|
||||
},
|
||||
{
|
||||
label: "Career Preparation Resources",
|
||||
link: "/mentorship/resources/career-prep",
|
||||
},
|
||||
].sort((a, b) => a.label.localeCompare(b.label)),
|
||||
}
|
||||
].sort((a, b) => a.label.localeCompare(b.label)),
|
||||
},
|
||||
{
|
||||
|
||||
@@ -49,41 +49,47 @@ By enrolling in the Programme, Mentees acknowledge and agree that they have:
|
||||
|
||||
**Channel Access:**
|
||||
**(a)** Mentees receive access to private Discord channels exclusively for Programme participants;
|
||||
**(b)** These channels receive priority response times from our team;
|
||||
**(b)** These channels provide a space for peer support, questions, and community engagement;
|
||||
**(c)** All participants must adhere to our [Community Code of Conduct](/community/coc) and Programme-specific guidelines;
|
||||
**(d)** We reserve the right to restrict or revoke channel access for violations of community standards or Programme terms.
|
||||
**(d)** We reserve the right to restrict or revoke channel access for violations of community standards or Programme terms;
|
||||
**(e)** Response times from programme leadership vary based on availability; the programme is designed to be self-guided.
|
||||
|
||||
### 3.2. Flagship Project Development
|
||||
|
||||
**Project Access and Support:**
|
||||
**(a)** Mentees gain maintainer-level access to a repository under our [Mentorship GitHub organisation](https://github.com/NHCarrigan-mentorship);
|
||||
**(b)** Mentees use this repository to build their flagship project under the guidance of our team;
|
||||
**(c)** Project support and guidance are provided subject to mentor availability and Programme resources;
|
||||
**(d)** We do not guarantee specific project outcomes, completion, or success.
|
||||
**(b)** Mentees use this repository to build their flagship project using self-guided documentation and resources;
|
||||
**(c)** Project support and guidance are available upon request, subject to mentor availability and Programme resources;
|
||||
**(d)** The programme is designed to be self-guided with comprehensive documentation, templates, and examples;
|
||||
**(e)** We do not guarantee specific project outcomes, completion, or success.
|
||||
|
||||
### 3.3. Career Preparation and Resume Building
|
||||
|
||||
**Career Development Services:**
|
||||
**(a)** Mentees have the opportunity to build their resumes through internship-style experiences with NHCarrigan;
|
||||
**(b)** This includes eligibility for project contributions and collaboration with our team;
|
||||
**(c)** Career preparation services are provided for educational and development purposes;
|
||||
**(d)** We do not guarantee employment, job placement, or specific career outcomes.
|
||||
**Career Development Resources:**
|
||||
**(a)** Mentees have access to comprehensive career preparation resources including resume templates, LinkedIn guides, application examples, and interview preparation materials;
|
||||
**(b)** Career preparation is primarily self-guided using provided resources and templates;
|
||||
**(c)** Optional support and feedback are available upon request, subject to mentor availability;
|
||||
**(d)** Career preparation resources are provided for educational and development purposes;
|
||||
**(e)** We do not guarantee employment, job placement, or specific career outcomes.
|
||||
|
||||
### 3.4. Ongoing Support and Resources
|
||||
### 3.4. Ongoing Resources and Support
|
||||
|
||||
**Continuous Support Services:**
|
||||
**(a)** Mentees receive continuous resume reviews, personalised learning roadmaps, and dedicated guidance for the duration of their membership;
|
||||
**(b)** Additional resources and Programme updates are provided as part of membership support;
|
||||
**(c)** Support services are subject to mentor availability and Programme capacity;
|
||||
**(d)** We reserve the right to modify or discontinue specific support services with reasonable notice.
|
||||
**Resource Library and Support:**
|
||||
**(a)** Mentees have access to a comprehensive resource library including templates, examples, guides, and checklists for all programme stages;
|
||||
**(b)** The programme is designed to be self-guided with participants working at their own pace;
|
||||
**(c)** Optional support, reviews, and feedback are available upon request, subject to mentor availability and Programme capacity;
|
||||
**(d)** Additional resources and Programme updates are provided as part of programme participation;
|
||||
**(e)** We reserve the right to modify or discontinue specific resources or support services with reasonable notice.
|
||||
|
||||
### 3.5. Service Limitations and Disclaimers
|
||||
|
||||
**IMPORTANT DISCLAIMERS:**
|
||||
**(a)** Programme services are provided "as is" without warranties of any kind;
|
||||
**(b)** We do not guarantee specific learning outcomes, skill development, or career advancement;
|
||||
**(c)** Programme benefits and services may vary based on mentor availability, resource constraints, and Programme capacity;
|
||||
**(d)** We reserve the right to modify Programme features, benefits, and services at any time with reasonable notice.
|
||||
**(a)** Programme services and resources are provided "as is" without warranties of any kind;
|
||||
**(b)** The programme is self-guided; participants are responsible for their own learning and progress;
|
||||
**(c)** We do not guarantee specific learning outcomes, skill development, or career advancement;
|
||||
**(d)** Programme benefits, resources, and support may vary based on mentor availability, resource constraints, and Programme capacity;
|
||||
**(e)** Reviews, approvals, and support are optional and provided when requested and available, not guaranteed;
|
||||
**(f)** We reserve the right to modify Programme features, benefits, and services at any time with reasonable notice.
|
||||
|
||||
## 4. CODE OF CONDUCT AND PARTICIPATION STANDARDS
|
||||
|
||||
@@ -98,10 +104,11 @@ By enrolling in the Programme, Mentees acknowledge and agree that they have:
|
||||
### 4.2. Programme Participation Standards
|
||||
|
||||
**Participation Requirements:**
|
||||
**(a)** Mentees are expected to actively engage with Programme resources and activities;
|
||||
**(a)** Mentees are expected to actively engage with Programme resources and work through programme documentation at their own pace;
|
||||
**(b)** Mentees must maintain respectful and professional conduct in all Programme interactions;
|
||||
**(c)** Mentees are responsible for their own learning and development progress;
|
||||
**(d)** We reserve the right to terminate Programme participation for failure to meet participation standards.
|
||||
**(d)** The programme is self-guided; participants work independently using provided resources;
|
||||
**(e)** We reserve the right to terminate Programme participation for failure to meet participation standards or violations of community standards.
|
||||
|
||||
## 5. PROGRAMME MODIFICATIONS AND CHANGES
|
||||
|
||||
@@ -117,8 +124,8 @@ By enrolling in the Programme, Mentees acknowledge and agree that they have:
|
||||
|
||||
**Discontinuation Rights:**
|
||||
**(a)** We reserve the right to discontinue the Programme at any time with reasonable notice to enrolled Mentees;
|
||||
**(b)** In the event of Programme discontinuation, we will provide prorated refunds for unused Programme fees;
|
||||
**(c)** We are not liable for any consequences arising from Programme discontinuation beyond fee refunds;
|
||||
**(b)** In the event of Programme discontinuation, we will provide reasonable notice to participants;
|
||||
**(c)** We are not liable for any consequences arising from Programme discontinuation;
|
||||
**(d)** Programme discontinuation does not affect accrued obligations or rights established prior to discontinuation.
|
||||
|
||||
## 6. TERMINATION AND CANCELLATION
|
||||
@@ -126,18 +133,18 @@ By enrolling in the Programme, Mentees acknowledge and agree that they have:
|
||||
### 6.1. Mentee Cancellation Rights
|
||||
|
||||
**Cancellation Process:**
|
||||
**(a)** Mentees may cancel their Programme membership at any time by providing written notice to our team;
|
||||
**(b)** Cancellation notices should indicate the Mentee's desire to withdraw and the reason for leaving;
|
||||
**(c)** Cancellation becomes effective at the end of the current billing period;
|
||||
**(d)** Fees paid for the current billing period are non-refundable upon cancellation.
|
||||
**(a)** Mentees may withdraw from the Programme at any time by providing written notice to our team;
|
||||
**(b)** Withdrawal notices should indicate the Mentee's desire to withdraw and the reason for leaving;
|
||||
**(c)** Withdrawal becomes effective immediately upon receipt of notice;
|
||||
**(d)** No fees or penalties apply to voluntary withdrawal.
|
||||
|
||||
### 6.2. Company Termination Rights
|
||||
|
||||
**Termination Authority:**
|
||||
**(a)** We reserve the right to terminate Programme participation for violations of these Terms, Community Code of Conduct, or applicable policies;
|
||||
**(b)** We may terminate Programme participation for non-payment of fees or failure to meet participation standards;
|
||||
**(b)** We may terminate Programme participation for failure to meet participation standards or violations of community standards;
|
||||
**(c)** Termination may be immediate for serious violations or with notice for other circumstances;
|
||||
**(d)** We are not obligated to provide refunds for terminated Programme participation.
|
||||
**(d)** We are not obligated to provide continued access following termination.
|
||||
|
||||
### 6.3. Effect of Termination
|
||||
|
||||
@@ -195,25 +202,26 @@ By enrolling in the Programme, Mentees acknowledge and agree that they have:
|
||||
**(a)** We are not liable for Mentee learning outcomes, career advancement, or professional success;
|
||||
**(b)** We do not guarantee job placement, employment opportunities, or specific career outcomes;
|
||||
**(c)** We are not responsible for Mentee decisions made based on Programme guidance or resources;
|
||||
**(d)** Our liability is limited to the maximum extent permitted by applicable law and Programme fees paid.
|
||||
**(d)** Our liability is limited to the maximum extent permitted by applicable law.
|
||||
|
||||
## 10. PAYMENT TERMS AND REFUND POLICY
|
||||
## 10. PROGRAMME FEES
|
||||
|
||||
### 10.1. Payment Obligations
|
||||
### 10.1. Free Programme
|
||||
|
||||
**Payment Requirements:**
|
||||
**(a)** Programme fees are due in advance on a monthly basis;
|
||||
**(b)** Payments must be made through designated payment methods;
|
||||
**(c)** Failure to pay fees may result in Programme suspension or termination;
|
||||
**(d)** We reserve the right to modify payment terms with reasonable notice.
|
||||
**No Fees:**
|
||||
**(a)** The Mentorship Programme is offered entirely free of charge;
|
||||
**(b)** We do not collect tuition fees, academic fees, or any other programme-related charges;
|
||||
**(c)** Participants may incur costs for third-party services such as hosting for application deployment;
|
||||
**(d)** All such costs are paid directly to third-party service providers;
|
||||
**(e)** Our organisation does not collect, process, or receive any payments related to these third-party services.
|
||||
|
||||
### 10.2. Refund Policy
|
||||
### 10.2. Voluntary Donations
|
||||
|
||||
**Refund Terms:**
|
||||
**(a)** Programme fees are generally non-refundable;
|
||||
**(b)** Refunds may be provided for Programme discontinuation or our failure to provide agreed services;
|
||||
**(c)** Refund requests must be submitted in writing and are subject to our review and approval;
|
||||
**(d)** Processing fees charged by payment platforms are non-refundable.
|
||||
**Donation Policy:**
|
||||
**(a)** We welcome voluntary donations to support programme operations;
|
||||
**(b)** Donations are entirely optional and do not affect programme participation or outcomes;
|
||||
**(c)** Information about donation options is available at: [https://donate.nhcarrigan.com/](https://donate.nhcarrigan.com/);
|
||||
**(d)** Donations do not create any obligations or entitlements beyond those set forth in these Terms.
|
||||
|
||||
## 11. CONTACT INFORMATION AND SUPPORT
|
||||
|
||||
@@ -242,7 +250,7 @@ For general inquiries about our organisation or services:
|
||||
By enrolling in the Programme, Mentees acknowledge that they have:
|
||||
**(a)** Read, understood, and agree to be bound by these Terms;
|
||||
**(b)** Reviewed and agree to comply with all applicable policies and community standards;
|
||||
**(c)** Understood the Programme fees, payment obligations, and refund policy;
|
||||
**(c)** Understood that the Programme is free and self-guided;
|
||||
**(d)** Acknowledged all disclaimers, limitations, and legal protections incorporated by reference.
|
||||
|
||||
### 12.2. Entire Agreement
|
||||
|
||||
@@ -34,19 +34,39 @@ This FAQ addresses common questions and concerns regarding programme participati
|
||||
- Donations are entirely optional and do not affect programme participation or outcomes
|
||||
- Information about donation options is available at: [https://donate.nhcarrigan.com/](https://donate.nhcarrigan.com/)
|
||||
|
||||
## 3. COMMUNICATION AND RESPONSE TIMELINES
|
||||
## 3. PROGRAMME STRUCTURE AND SUPPORT
|
||||
|
||||
### 3.1. Response Time Expectations
|
||||
### 3.1. Self-Guided Programme Structure
|
||||
|
||||
**Question: Why does Naomi take so long to respond?**
|
||||
**Question: How does the mentorship programme work?**
|
||||
|
||||
**Answer:** We strive to respond to all communications as promptly as possible. However, please understand that:
|
||||
**Answer:** Our Mentorship Programme is designed to be self-guided and self-managed. The programme structure includes:
|
||||
|
||||
- **Self-Guided Documentation:** Comprehensive guides and templates for each stage of development
|
||||
- **Resource Library:** Templates, examples, and checklists to support independent learning
|
||||
- **On-Demand Support:** Programme leadership and community members available to answer questions when asked
|
||||
- **Flexible Timeline:** Work at your own pace with no mandatory deadlines or review requirements
|
||||
|
||||
**Programme Philosophy:**
|
||||
- Participants follow documentation and use provided resources independently
|
||||
- Reviews and approvals are optional and available upon request
|
||||
- Support is provided when participants ask for help, not through mandatory checkpoints
|
||||
- Community and peer support is encouraged throughout the programme
|
||||
|
||||
### 3.2. Response Time Expectations
|
||||
|
||||
**Question: How quickly will I get responses to my questions?**
|
||||
|
||||
**Answer:** The programme is designed to be self-guided, so you can progress independently without waiting for responses. However, when you do have questions:
|
||||
|
||||
- The Mentorship Programme is provided on a voluntary basis without compensation
|
||||
- Programme leadership maintains multiple paid employment positions to cover personal expenses
|
||||
- Response times may vary based on workload, availability, and other commitments
|
||||
- Community members and alumni may also provide assistance
|
||||
|
||||
**Response Time Guidelines:**
|
||||
- Most programme activities can be completed independently using provided documentation
|
||||
- If you have questions, feel free to ask in the #mentee-chat channel
|
||||
- If you have not received a response within three (3) business days, you may send a gentle reminder
|
||||
- Repeated communications at intervals of less than three (3) days may result in disciplinary action
|
||||
- We appreciate your patience and understanding regarding response timelines
|
||||
@@ -117,8 +137,11 @@ All expulsion decisions are made in accordance with our Mentorship Programme Ter
|
||||
|
||||
**Answer:** For questions not addressed in this FAQ:
|
||||
|
||||
- Review the comprehensive mentorship documentation (01-10) for detailed guidance on each programme stage
|
||||
- Check the resource library for templates, examples, and additional materials
|
||||
- Contact programme leadership through the designated #mentee-chat channel in our Discord community
|
||||
- Programme leadership is available to answer questions and provide clarification
|
||||
- Ask community members and alumni for peer support and guidance
|
||||
- Programme leadership is available to answer questions when asked, but most activities can be completed independently
|
||||
- Additional information is available in our comprehensive [Mentorship Programme Terms and Conditions](/about/mentorship)
|
||||
|
||||
## 7. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -14,7 +14,7 @@ This Onboarding Documentation (hereinafter referred to as "the Documentation") e
|
||||
|
||||
This Documentation applies to all individuals who have been accepted into our Mentorship Programme. All participants must complete the onboarding procedures set forth in this Documentation to gain full programme access.
|
||||
|
||||
**IMPORTANT: Failure to complete onboarding procedures within specified timeframes may result in withdrawal of programme acceptance and forfeiture of programme participation opportunities.**
|
||||
**IMPORTANT: This is a self-guided programme. Once you complete onboarding, you can work through the programme documentation at your own pace. Reviews and approvals are optional and available upon request.**
|
||||
|
||||
## 2. APPLICATION ACCEPTANCE AND CONFIRMATION
|
||||
|
||||
@@ -105,8 +105,9 @@ Onboarding is considered complete when:
|
||||
Upon completion of onboarding procedures, participants gain full access to:
|
||||
- Programme-specific Discord channels
|
||||
- GitHub repository for flagship project development
|
||||
- Programme resources and documentation
|
||||
- Mentorship sessions and coaching activities
|
||||
- Programme resources and documentation (self-guided guides 01-10)
|
||||
- Resource library with templates, examples, and checklists
|
||||
- On-demand support from programme leadership and community members
|
||||
|
||||
## 6. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -119,7 +120,8 @@ Upon completion of onboarding procedures, participants gain full access to:
|
||||
This Documentation establishes mandatory onboarding procedures. However:
|
||||
|
||||
- Programme leadership reserves the right to modify onboarding procedures at any time
|
||||
- Failure to complete onboarding within specified timeframes may result in programme access delays or withdrawal
|
||||
- Once onboarding is complete, the programme is self-guided and participants work at their own pace
|
||||
- Reviews and approvals are optional and available upon request
|
||||
- Programme leadership is not responsible for technical issues preventing onboarding completion beyond our reasonable control
|
||||
|
||||
## 7. CONCLUSION
|
||||
|
||||
@@ -12,9 +12,9 @@ This Goal-Setting Documentation (hereinafter referred to as "the Documentation")
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of onboarding procedures. All participants must complete the goal-setting process set forth in this Documentation to proceed with programme activities.
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of onboarding procedures. All participants should complete the goal-setting process set forth in this Documentation to proceed with programme activities.
|
||||
|
||||
**IMPORTANT: Goal-setting is a mandatory component of programme participation. Failure to complete goal-setting procedures may delay or prevent progression to project planning and development stages.**
|
||||
**IMPORTANT: This is a self-guided process. You will create your own roadmap using provided templates and examples. No approval is required to proceed.**
|
||||
|
||||
## 2. GOAL-SETTING INITIATION
|
||||
|
||||
@@ -60,60 +60,72 @@ Goal-setting procedures must be initiated following completion of onboarding pro
|
||||
- This information assists in aligning programme activities with your personal motivations
|
||||
- Helps programme leadership tailor mentorship approaches to your individual needs
|
||||
|
||||
### 2.4. Follow-Up Questions and Clarification
|
||||
### 2.4. Optional Feedback and Clarification
|
||||
|
||||
Programme leadership may request additional information or clarification through follow-up questions. Participants are expected to respond promptly and thoroughly to facilitate effective goal-setting and roadmap development.
|
||||
If you would like feedback on your goal-setting post or have questions about creating your roadmap, you can:
|
||||
- Ask questions in the #mentee-chat channel in Discord
|
||||
- Request feedback from programme leadership or community members
|
||||
- Review roadmap templates and examples in the resource library
|
||||
- Proceed independently if you feel confident in your goals and plan
|
||||
|
||||
## 3. ROADMAP DEVELOPMENT AND CONFIRMATION
|
||||
## 3. ROADMAP DEVELOPMENT
|
||||
|
||||
### 3.1. Twelve-Week Roadmap Provision
|
||||
### 3.1. Self-Guided Roadmap Creation
|
||||
|
||||
To finalise the goal-setting process, programme leadership will provide a comprehensive twelve (12) week roadmap outlining:
|
||||
To finalise the goal-setting process, you will create your own learning roadmap using provided templates and examples.
|
||||
|
||||
**Roadmap Templates Available:**
|
||||
- Template roadmaps are available for common career paths (front-end, back-end, full-stack, mobile, game development, etc.)
|
||||
- Templates include suggested learning objectives, milestones, and skill development activities
|
||||
- Templates can be customized to fit your individual circumstances and goals
|
||||
|
||||
**Roadmap Components:**
|
||||
Your roadmap should outline:
|
||||
- Learning objectives and milestones
|
||||
- Flagship project development timeline
|
||||
- Flagship project development timeline (flexible, no deadlines required)
|
||||
- Skill development activities and resources
|
||||
- Programme progression expectations
|
||||
|
||||
### 3.2. Roadmap Review and Assessment
|
||||
### 3.2. Roadmap Customization
|
||||
|
||||
**Participant Responsibilities:**
|
||||
- Review the provided roadmap thoroughly and completely
|
||||
- Assess whether the roadmap appears achievable given your circumstances
|
||||
- Evaluate whether the roadmap aligns with your programme goals
|
||||
- Verify that the roadmap incorporates your stated interests and preferences
|
||||
**Self-Assessment:**
|
||||
- Review available roadmap templates and select one that aligns with your career goals
|
||||
- Assess whether the template appears achievable given your circumstances
|
||||
- Evaluate whether the template aligns with your programme goals
|
||||
- Customize the template to incorporate your stated interests and preferences
|
||||
|
||||
**Review Considerations:**
|
||||
**Customization Considerations:**
|
||||
- Timeline feasibility given your availability and commitments
|
||||
- Alignment with your career objectives and learning goals
|
||||
- Incorporation of your interests and motivations
|
||||
- Realistic assessment of your current skill level and learning capacity
|
||||
|
||||
### 3.3. Roadmap Flexibility and Adaptation
|
||||
### 3.3. Roadmap Flexibility
|
||||
|
||||
**Flexibility Principle:**
|
||||
- Roadmaps are designed to provide structure and guidance, not rigid constraints
|
||||
- Programme leadership will adapt roadmaps to accommodate changes in:
|
||||
- Participant circumstances and availability
|
||||
- You can modify your roadmap at any time to accommodate changes in:
|
||||
- Your circumstances and availability
|
||||
- Timeline requirements and constraints
|
||||
- Learning progress and skill development
|
||||
- Project scope and complexity adjustments
|
||||
|
||||
**Adaptation Process:**
|
||||
- Participants may request roadmap modifications as circumstances change
|
||||
- Programme leadership will work collaboratively to adjust roadmaps when necessary
|
||||
- Regular check-ins provide opportunities for roadmap refinement
|
||||
- Update your roadmap as circumstances change
|
||||
- No approval is required for roadmap modifications
|
||||
- You work at your own pace with no mandatory deadlines
|
||||
|
||||
### 3.4. Roadmap Confirmation
|
||||
### 3.4. Roadmap Completion
|
||||
|
||||
**Confirmation Requirement:**
|
||||
- Participants must provide explicit confirmation of roadmap acceptance
|
||||
- Confirmation indicates agreement with the proposed learning and development plan
|
||||
- Roadmap confirmation is required before progression to project planning stages
|
||||
**No Confirmation Required:**
|
||||
- You do not need approval or confirmation to proceed
|
||||
- Once you have created your roadmap, you are ready to proceed to project planning
|
||||
- Your roadmap is a personal planning tool to guide your learning journey
|
||||
|
||||
**Post-Confirmation:**
|
||||
- Upon roadmap confirmation, participants are ready to proceed to project planning
|
||||
**Next Steps:**
|
||||
- Upon creating your roadmap, you are ready to proceed to project planning
|
||||
- Project planning procedures are outlined in our [Project Planning Documentation](/mentorship/03-project-plan)
|
||||
- Optional: You may share your roadmap in Discord if you'd like feedback, but this is not required
|
||||
|
||||
## 4. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -126,9 +138,11 @@ To finalise the goal-setting process, programme leadership will provide a compre
|
||||
This Documentation establishes goal-setting procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify goal-setting procedures at any time
|
||||
- Roadmaps are provided as guidance and do not guarantee specific outcomes or achievements
|
||||
- Roadmap templates are provided as guidance and do not guarantee specific outcomes or achievements
|
||||
- Participants create their own roadmaps and are responsible for their own learning progress
|
||||
- Programme leadership is not responsible for participants' ability to achieve roadmap objectives
|
||||
- Individual results may vary based on participant effort, circumstances, and other factors
|
||||
- Reviews and approvals are optional and available upon request
|
||||
|
||||
## 5. CONCLUSION
|
||||
|
||||
|
||||
@@ -12,9 +12,9 @@ This Project Planning Documentation (hereinafter referred to as "the Documentati
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of goal-setting procedures. All participants must complete the project planning process set forth in this Documentation to proceed with flagship project development.
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of goal-setting procedures. All participants should complete the project planning process set forth in this Documentation to proceed with flagship project development.
|
||||
|
||||
**IMPORTANT: Project planning is a mandatory component of programme participation. Failure to complete project planning procedures may delay or prevent progression to project development stages.**
|
||||
**IMPORTANT: This is a self-guided process. You will create your own project plan using provided examples and templates. No approval is required to proceed.**
|
||||
|
||||
## 2. PROJECT PLANNING INITIATION
|
||||
|
||||
@@ -50,24 +50,31 @@ Project planning procedures must be initiated following completion of goal-setti
|
||||
|
||||
**Project Idea Assistance:**
|
||||
- If you do not yet have a project idea, create your post with a statement such as: "I need help brainstorming a project idea"
|
||||
- Programme leadership will work collaboratively with you to develop a project concept
|
||||
- Project ideas will be evaluated for alignment with your goals and programme objectives
|
||||
- Programme leadership will assist in refining project ideas to ensure feasibility and educational value
|
||||
- Review project idea examples in the resource library for inspiration
|
||||
- Ask for help in the #mentee-chat channel if you'd like community input
|
||||
- Programme leadership and community members can provide feedback if requested
|
||||
- You can also proceed independently by researching project ideas online or adapting examples
|
||||
|
||||
## 3. PROJECT PLAN DEVELOPMENT AND REFINEMENT
|
||||
## 3. PROJECT PLAN DEVELOPMENT
|
||||
|
||||
### 3.1. Collaborative Development Process
|
||||
### 3.1. Self-Guided Development Process
|
||||
|
||||
Once your project planning post is created, programme leadership will work with you to:
|
||||
Once your project planning post is created, you will develop your project plan independently. Use the following guidance:
|
||||
|
||||
- Review project plan examples in the resource library
|
||||
- Flesh out and refine your project concept
|
||||
- Develop comprehensive project specifications
|
||||
- Establish technical requirements and architecture considerations
|
||||
- Create a detailed project plan ready for development work
|
||||
|
||||
**Optional Support:**
|
||||
- If you need help brainstorming or refining your project idea, ask in the #mentee-chat channel
|
||||
- Community members and programme leadership can provide feedback if requested
|
||||
- You can proceed independently once you have a project concept you're happy with
|
||||
|
||||
### 3.2. Project Plan Example
|
||||
|
||||
Upon completion of the collaborative development process, you should have a comprehensive project plan. The following example illustrates the level of detail expected:
|
||||
The following example illustrates the level of detail expected in a comprehensive project plan:
|
||||
|
||||
```markdown
|
||||
A life task tracker app thats open source and self-hosted as well as a live version hosted on my website with user auth and such. Could have kanban boards and different views and such, and have tasks that depend on other tasks just like on a github projects board.
|
||||
@@ -75,19 +82,21 @@ A life task tracker app thats open source and self-hosted as well as a live vers
|
||||
Could also link rewards to tasks / projects. e.g. Car Maintenance project with sub tasks of cleaning car, changing oil, buying car charger for cig lighter port etc, and then could link to an item that you will buy for yourself as a reward for when the entire project is complete, and itll have a link to that item when you mark the project as complete
|
||||
|
||||
At the end I could sneak some gamification elements in as an opt-in thing where you can level up and such by completing tasks / projects/ completing life goals).
|
||||
|
||||
```
|
||||
|
||||
### 3.3. Project Plan Approval
|
||||
Additional project plan examples are available in the resource library.
|
||||
|
||||
**Final Sign-Off:**
|
||||
- Programme leadership will provide final approval of your project plan
|
||||
- Approval indicates that the project plan meets programme standards and requirements
|
||||
- Project plan approval is required before progression to user story development
|
||||
### 3.3. Project Plan Completion
|
||||
|
||||
**Post-Approval:**
|
||||
- Upon project plan approval, participants are ready to proceed to user story development
|
||||
**No Approval Required:**
|
||||
- You do not need approval or sign-off to proceed
|
||||
- Once you have created your project plan, you are ready to proceed to user story development
|
||||
- Your project plan is a living document that you can update as needed
|
||||
|
||||
**Next Steps:**
|
||||
- Upon creating your project plan, you are ready to proceed to user story development
|
||||
- User story development procedures are outlined in our [User Stories Documentation](/mentorship/04-user-stories)
|
||||
- Optional: You may share your project plan in Discord if you'd like feedback, but this is not required
|
||||
|
||||
## 4. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -100,9 +109,10 @@ At the end I could sneak some gamification elements in as an opt-in thing where
|
||||
This Documentation establishes project planning procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify project planning procedures at any time
|
||||
- Project plans are provided as guidance and do not guarantee specific project outcomes
|
||||
- Project plans are created by participants and serve as guidance, not guarantees
|
||||
- Programme leadership is not responsible for participants' ability to complete projects as planned
|
||||
- Individual results may vary based on participant effort, circumstances, and other factors
|
||||
- Reviews and approvals are optional and available upon request
|
||||
|
||||
### 4.3. Intellectual Property Considerations
|
||||
|
||||
|
||||
@@ -12,9 +12,9 @@ This User Stories Documentation (hereinafter referred to as "the Documentation")
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of project planning procedures. All participants must complete the user story development process set forth in this Documentation to proceed with technical breakdown and development stages.
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of project planning procedures. All participants should complete the user story development process set forth in this Documentation to proceed with technical breakdown and development stages.
|
||||
|
||||
**IMPORTANT: User story development is a mandatory component of programme participation. Failure to complete user story development procedures may delay or prevent progression to technical breakdown and development stages.**
|
||||
**IMPORTANT: This is a self-guided process. You will create user stories independently using provided templates and examples. No review or approval is required to proceed.**
|
||||
|
||||
## 2. USER STORY DEVELOPMENT REQUIREMENTS
|
||||
|
||||
@@ -82,26 +82,28 @@ Separate issues provide:
|
||||
- Improved collaboration and communication regarding specific features
|
||||
- Enhanced ability to prioritise and schedule development work
|
||||
|
||||
## 5. USER STORY REVIEW AND APPROVAL
|
||||
## 5. USER STORY COMPLETION
|
||||
|
||||
### 5.1. Review Request Process
|
||||
### 5.1. Optional Review Process
|
||||
|
||||
**Required Action:** Once you have created all user stories as individual issues, you must:
|
||||
**No Review Required:**
|
||||
- You do not need to request review or approval to proceed
|
||||
- Once you have created all user stories as individual issues, you are ready to proceed to technical breakdown
|
||||
- Your user stories are a living document that you can update as needed
|
||||
|
||||
- Contact programme leadership through the #mentee-chat channel in our Discord community
|
||||
- Request final review of your user stories
|
||||
- Provide access to your repository for review purposes
|
||||
**Optional Review:**
|
||||
- If you would like feedback on your user stories, you can:
|
||||
- Request review in the #mentee-chat channel in Discord
|
||||
- Ask community members or alumni for peer review
|
||||
- Review user story examples in the resource library for comparison
|
||||
- Reviews are optional and available upon request, not required
|
||||
|
||||
### 5.2. Review and Sign-Off
|
||||
### 5.2. Next Steps
|
||||
|
||||
**Review Process:**
|
||||
- Programme leadership will review all user stories for completeness and quality
|
||||
- Feedback may be provided regarding user story format, clarity, or scope
|
||||
- Programme leadership will provide sign-off when user stories meet programme standards
|
||||
|
||||
**Post-Approval:**
|
||||
- Upon sign-off of user stories, participants are ready to proceed to technical breakdown
|
||||
**Proceeding to Technical Breakdown:**
|
||||
- Upon creating your user stories, you are ready to proceed to technical breakdown
|
||||
- Technical breakdown procedures are outlined in our [Technical Breakdown Documentation](/mentorship/05-technical-breakdown)
|
||||
- You can always return to refine your user stories later if needed
|
||||
|
||||
## 6. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -114,9 +116,10 @@ Separate issues provide:
|
||||
This Documentation establishes user story development procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify user story development procedures at any time
|
||||
- User stories are provided as guidance and do not guarantee specific project outcomes
|
||||
- User stories are created by participants and serve as guidance, not guarantees
|
||||
- Programme leadership is not responsible for participants' ability to complete user stories as planned
|
||||
- Individual results may vary based on participant effort, circumstances, and other factors
|
||||
- Reviews and approvals are optional and available upon request
|
||||
|
||||
## 7. CONCLUSION
|
||||
|
||||
|
||||
@@ -12,27 +12,19 @@ This Technical Breakdown Documentation (hereinafter referred to as "the Document
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of user story development procedures. All participants must complete the technical breakdown process set forth in this Documentation to proceed with development work.
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of user story development procedures. All participants should complete the technical breakdown process set forth in this Documentation to proceed with development work.
|
||||
|
||||
**IMPORTANT: Technical breakdown is a mandatory component of programme participation. Failure to complete technical breakdown procedures may delay or prevent progression to development stages.**
|
||||
**IMPORTANT: This is a self-guided process. You will fill out technical breakdown templates independently for each user story. No review or approval is required to proceed.**
|
||||
|
||||
## 2. TECHNICAL BREAKDOWN INITIATION
|
||||
|
||||
### 2.1. Timing and Prerequisites
|
||||
|
||||
Technical breakdown procedures must be initiated following completion of user story development and approval as outlined in our [User Stories Documentation](/mentorship/04-user-stories).
|
||||
Technical breakdown procedures should be initiated following completion of user story development as outlined in our [User Stories Documentation](/mentorship/04-user-stories).
|
||||
|
||||
### 2.2. User Story Audit and Review
|
||||
### 2.2. Technical Breakdown Template
|
||||
|
||||
Once your user stories are complete, programme leadership will audit them. The audit process may include:
|
||||
|
||||
- Review of user story completeness and quality
|
||||
- Feedback regarding user story format, clarity, or scope
|
||||
- Sign-off when user stories meet programme standards
|
||||
|
||||
### 2.3. Technical Breakdown Template Provision
|
||||
|
||||
Programme leadership will sign off on approved user stories by editing the issue to include the technical breakdown template set forth in Section 3 of this Documentation.
|
||||
You will add the technical breakdown template (set forth in Section 3 of this Documentation) to each user story issue yourself. The template is provided below for your reference.
|
||||
|
||||
```markdown
|
||||
## 🎯 Acceptance Criteria
|
||||
@@ -73,16 +65,16 @@ Programme leadership will sign off on approved user stories by editing the issue
|
||||
|
||||
```
|
||||
|
||||
### 2.4. Template Purpose and Requirements
|
||||
### 2.3. Template Purpose and Requirements
|
||||
|
||||
**Template Purpose:**
|
||||
This template is specifically designed to help participants understand how to break down user stories into actionable technical components.
|
||||
This template is specifically designed to help you understand how to break down user stories into actionable technical components.
|
||||
|
||||
**Completion Requirements:**
|
||||
- Participants must fill out the technical breakdown template for each approved user story
|
||||
- Template completion must be thorough and detailed
|
||||
- All sections of the template must be addressed to the best of the participant's ability
|
||||
- Programme leadership may provide guidance and feedback during template completion
|
||||
- Fill out the technical breakdown template for each user story
|
||||
- Template completion should be thorough and detailed
|
||||
- Address all sections of the template to the best of your ability
|
||||
- You can ask for guidance in Discord if you have questions, but this is optional
|
||||
|
||||
**Planning Importance:**
|
||||
- Comprehensive planning at this stage reduces the need for refactoring during development
|
||||
@@ -175,16 +167,29 @@ The following example demonstrates proper technical breakdown completion. For a
|
||||
|
||||
### 5.1. Completion Requirements
|
||||
|
||||
Participants must complete the technical breakdown template for each approved user story. Completion includes:
|
||||
Complete the technical breakdown template for each user story. Completion includes:
|
||||
|
||||
- Filling out all sections of the template to the best of your ability
|
||||
- Providing detailed, specific information in each section
|
||||
- Identifying dependencies, testing requirements, and technical considerations
|
||||
- Seeking clarification from programme leadership when needed
|
||||
- Seeking clarification from programme leadership or community members if needed (optional)
|
||||
|
||||
### 5.2. Review and Approval
|
||||
### 5.2. Optional Review
|
||||
|
||||
Programme leadership will review completed technical breakdowns and may provide feedback or request additional information. Upon approval of technical breakdowns, participants may proceed to priority and effort assignment as outlined in our [Priority and Effort Documentation](/mentorship/06-priority-and-effort).
|
||||
**No Review Required:**
|
||||
- You do not need review or approval to proceed
|
||||
- Once you have completed technical breakdowns for your user stories, you are ready to proceed to priority and effort assignment
|
||||
- Your technical breakdowns are living documents that you can update as needed
|
||||
|
||||
**Optional Review:**
|
||||
- If you would like feedback on your technical breakdowns, you can:
|
||||
- Request review in the #mentee-chat channel in Discord
|
||||
- Ask community members or alumni for peer review
|
||||
- Review technical breakdown examples in the resource library for comparison
|
||||
|
||||
**Next Steps:**
|
||||
- Upon completing your technical breakdowns, you are ready to proceed to priority and effort assignment
|
||||
- Priority and effort assignment procedures are outlined in our [Priority and Effort Documentation](/mentorship/06-priority-and-effort)
|
||||
|
||||
## 6. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -197,9 +202,10 @@ Programme leadership will review completed technical breakdowns and may provide
|
||||
This Documentation establishes technical breakdown procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify technical breakdown procedures at any time
|
||||
- Technical breakdowns are provided as guidance and do not guarantee specific implementation outcomes
|
||||
- Technical breakdowns are created by participants and serve as guidance, not guarantees
|
||||
- Programme leadership is not responsible for participants' ability to complete technical breakdowns as planned
|
||||
- Individual results may vary based on participant effort, technical knowledge, and other factors
|
||||
- Reviews and approvals are optional and available upon request
|
||||
|
||||
## 7. CONCLUSION
|
||||
|
||||
|
||||
@@ -12,9 +12,9 @@ This Priority and Effort Documentation (hereinafter referred to as "the Document
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of technical breakdown procedures. All participants must complete the priority and effort assignment process set forth in this Documentation to proceed with development work.
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of technical breakdown procedures. All participants should complete the priority and effort assignment process set forth in this Documentation to proceed with development work.
|
||||
|
||||
**IMPORTANT: Priority and effort assignment is a mandatory component of programme participation. Failure to complete these procedures may delay or prevent progression to development stages.**
|
||||
**IMPORTANT: This is a self-guided process. You will assign priority and effort labels independently. No review or approval is required to proceed.**
|
||||
|
||||
## 2. LABEL CREATION AND ASSIGNMENT
|
||||
|
||||
@@ -122,26 +122,28 @@ The purpose of applying effort labels is to help plan work timelines and resourc
|
||||
- This allows for progress even when time is restricted
|
||||
- Effort labels help balance priority with available time and resources
|
||||
|
||||
## 5. LABEL REVIEW AND APPROVAL
|
||||
## 5. LABEL COMPLETION
|
||||
|
||||
### 5.1. Review Request Process
|
||||
### 5.1. Completion Process
|
||||
|
||||
**Required Action:** Once you have applied priority and effort labels to all user stories, you must:
|
||||
**No Review Required:**
|
||||
- Once you have applied priority and effort labels to all user stories, you are ready to begin development work
|
||||
- No review or approval is required to proceed
|
||||
- Your labels are a planning tool that you can adjust as needed
|
||||
|
||||
- Contact programme leadership through the #mentee-chat channel in our Discord community
|
||||
- Request review of your priority and effort assignments
|
||||
- Be prepared to discuss your decisions and categorisation rationale
|
||||
**Optional Review:**
|
||||
- If you would like feedback on your priority and effort assignments, you can:
|
||||
- Request review in the #mentee-chat channel in Discord
|
||||
- Ask community members or alumni for peer review
|
||||
- Review priority and effort examples in the resource library for comparison
|
||||
- Reviews are optional and available upon request, not required
|
||||
|
||||
### 5.2. Review and Approval
|
||||
### 5.2. Next Steps
|
||||
|
||||
**Review Process:**
|
||||
- Programme leadership will review your priority and effort assignments
|
||||
- Discussion may occur regarding your categorisation decisions
|
||||
- Programme leadership will provide approval when labels meet programme standards
|
||||
|
||||
**Post-Approval:**
|
||||
- Upon approval of priority and effort labels, participants are ready to begin development work
|
||||
**Beginning Development:**
|
||||
- Upon completing priority and effort assignments, you are ready to begin development work
|
||||
- Development work should follow the procedures outlined in our [Contributing Documentation](/dev/contributing) and [Style Guide](/dev/style)
|
||||
- You can always adjust your priority and effort labels as you learn more about your project
|
||||
|
||||
## 6. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -154,9 +156,10 @@ The purpose of applying effort labels is to help plan work timelines and resourc
|
||||
This Documentation establishes priority and effort assignment procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify these procedures at any time
|
||||
- Priority and effort assignments are estimates and may change as development progresses
|
||||
- Priority and effort assignments are estimates created by participants and may change as development progresses
|
||||
- Programme leadership is not responsible for participants' ability to complete work within estimated effort levels
|
||||
- Individual results may vary based on participant skill, experience, and other factors
|
||||
- Reviews and approvals are optional and available upon request
|
||||
|
||||
## 7. CONCLUSION
|
||||
|
||||
|
||||
@@ -12,9 +12,9 @@ This Writing Code Documentation (hereinafter referred to as "the Documentation")
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of priority and effort assignment procedures. All participants must comply with the code development procedures set forth in this Documentation.
|
||||
This Documentation applies to all participants in our Mentorship Programme following completion of priority and effort assignment procedures. All participants should comply with the code development procedures set forth in this Documentation.
|
||||
|
||||
**IMPORTANT: Code development must comply with our Style Guide, Contributor Covenant, and all applicable development standards. Failure to comply with these requirements may result in rejection of contributions or other appropriate actions.**
|
||||
**IMPORTANT: Code development should comply with our Style Guide, Contributor Covenant, and all applicable development standards. Code reviews are optional and available upon request, not mandatory.**
|
||||
|
||||
## 2. DEVELOPMENT WORKFLOW REQUIREMENTS
|
||||
|
||||
@@ -54,18 +54,38 @@ Before writing code, participants must consider and address the requirements set
|
||||
|
||||
## 4. PULL REQUEST REVIEW PROCESS
|
||||
|
||||
### 4.1. Mandatory Review Requirement
|
||||
### 4.1. Optional Review Process
|
||||
|
||||
**Review Requirement:**
|
||||
- Every pull request requires review from programme leadership
|
||||
- Reviews ensure oversight of all development work
|
||||
- Reviews maintain alignment between participants and programme leadership
|
||||
- Reviews facilitate continuous learning and skill development
|
||||
**Self-Guided Development:**
|
||||
- Code reviews are optional and available upon request
|
||||
- You can merge your own pull requests without review if you choose
|
||||
- Use the provided code review checklist (see Section 4.2) for self-review
|
||||
- Community members and alumni may also provide peer reviews if requested
|
||||
|
||||
### 4.2. Review Standards
|
||||
**Requesting Reviews:**
|
||||
- If you would like a code review, request one in the #mentee-chat channel or tag programme leadership on your PR
|
||||
- Reviews are provided when available, not guaranteed immediately
|
||||
- You can proceed with development while waiting for reviews
|
||||
|
||||
### 4.2. Self-Review Checklist
|
||||
|
||||
**Code Review Checklist:**
|
||||
Before merging, consider reviewing your own code for:
|
||||
|
||||
- Best practices and industry standards
|
||||
- Code quality and maintainability
|
||||
- Feature completeness and functionality
|
||||
- Compliance with style guides and standards
|
||||
- Security considerations and best practices
|
||||
- Test coverage and quality
|
||||
- Documentation and comments
|
||||
|
||||
A detailed code review checklist is available in the resource library.
|
||||
|
||||
### 4.3. Review Standards (When Requested)
|
||||
|
||||
**Professional Review Standards:**
|
||||
Programme leadership will review code as if participants were working in a professional setting, evaluating:
|
||||
When reviews are requested, programme leadership or community reviewers will evaluate:
|
||||
|
||||
- Best practices and industry standards
|
||||
- Code quality and maintainability
|
||||
@@ -73,13 +93,11 @@ Programme leadership will review code as if participants were working in a profe
|
||||
- Compliance with style guides and standards
|
||||
- Security considerations and best practices
|
||||
|
||||
### 4.3. Review Communication
|
||||
|
||||
**Iterative Review Process:**
|
||||
- Pull request reviews typically involve back-and-forth communication
|
||||
**Review Communication:**
|
||||
- Reviews may involve back-and-forth communication
|
||||
- Review comments are designed to facilitate learning and skill improvement
|
||||
- Participants should view reviews as learning opportunities
|
||||
- Programme leadership emphasises that development is a marathon, not a sprint
|
||||
- Reviews should be viewed as learning opportunities
|
||||
- Remember that development is a marathon, not a sprint
|
||||
|
||||
## 5. PROJECT SCAFFOLDING AND SETUP
|
||||
|
||||
@@ -146,7 +164,8 @@ Upon completion of project scaffolding and setup, participants are authorised to
|
||||
This Documentation establishes code development procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify development procedures at any time
|
||||
- Code reviews do not guarantee acceptance of contributions
|
||||
- Code reviews are optional and provided when requested and available
|
||||
- Code reviews do not guarantee acceptance of contributions or specific feedback
|
||||
- Programme leadership is not responsible for participants' ability to complete development work
|
||||
- Individual results may vary based on participant skill, effort, and other factors
|
||||
|
||||
|
||||
@@ -12,111 +12,146 @@ This Final Polish Documentation (hereinafter referred to as "the Documentation")
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme whose flagship projects have reached a state suitable for resume presentation. All participants must complete the final polish procedures set forth in this Documentation before project completion.
|
||||
This Documentation applies to all participants in our Mentorship Programme whose flagship projects have reached a state suitable for resume presentation. All participants should complete the final polish procedures set forth in this Documentation before project completion.
|
||||
|
||||
**IMPORTANT: Final polish procedures are mandatory for programme completion. Failure to complete these procedures may delay programme graduation or project completion.**
|
||||
**IMPORTANT: This is a self-guided process. You will use provided checklists and templates to polish your project independently. Reviews and approvals are optional and available upon request.**
|
||||
|
||||
## 2. FINAL POLISH INITIATION
|
||||
|
||||
### 2.1. Readiness Assessment
|
||||
|
||||
When participants believe their flagship project has reached a state where it can be proudly shown on a resume, they must:
|
||||
When you believe your flagship project has reached a state where it can be proudly shown on a resume, you can begin final polish procedures using the provided checklists and templates.
|
||||
|
||||
- Contact programme leadership through the #mentee-chat channel in our Discord community
|
||||
- Request initiation of final polish procedures
|
||||
- Provide access to the project repository for review
|
||||
**Self-Assessment:**
|
||||
- Review the final polish checklist in the resource library
|
||||
- Assess your project against the checklist criteria
|
||||
- Begin addressing items on the checklist independently
|
||||
|
||||
### 2.2. Programme Leadership Review
|
||||
|
||||
Programme leadership will assess project readiness and initiate final polish procedures when appropriate.
|
||||
**Optional Support:**
|
||||
- If you would like feedback on project readiness, ask in the #mentee-chat channel
|
||||
- Programme leadership or community members can provide guidance if requested
|
||||
- You can proceed independently using the provided resources
|
||||
|
||||
## 3. CODE CLEANUP PROCESS
|
||||
|
||||
### 3.1. Comprehensive Code Review
|
||||
### 3.1. Self-Guided Code Review
|
||||
|
||||
**Review Process:**
|
||||
- Programme leadership will conduct a comprehensive review of the project
|
||||
- Review will identify issues requiring resolution
|
||||
- New issues will be created in the project repository for each identified concern
|
||||
**Self-Review Process:**
|
||||
- Use the comprehensive code review checklist provided in the resource library
|
||||
- Review your own code systematically against the checklist
|
||||
- Create issues in your repository for items that need attention
|
||||
- Address issues independently
|
||||
|
||||
### 3.2. Issue Resolution Cycle
|
||||
**Code Review Checklist Areas:**
|
||||
- Code quality and maintainability
|
||||
- Best practices and industry standards
|
||||
- Security considerations
|
||||
- Performance optimization
|
||||
- Error handling
|
||||
- Test coverage
|
||||
- Code organization and structure
|
||||
|
||||
**Iterative Process:**
|
||||
- Participants must address all identified issues
|
||||
- Programme leadership will review resolved issues
|
||||
- Additional issues may be identified during review
|
||||
- This cycle continues until the project meets polish standards
|
||||
### 3.2. Issue Resolution
|
||||
|
||||
**Self-Managed Process:**
|
||||
- Address issues you identify using the checklist
|
||||
- Update issues as you resolve them
|
||||
- Continue until you feel your project meets polish standards
|
||||
|
||||
**Optional Review:**
|
||||
- If you would like feedback on your code cleanup, request a review in Discord
|
||||
- Programme leadership or community members can provide feedback if requested
|
||||
- Reviews are optional and available upon request
|
||||
|
||||
**Completion Criteria:**
|
||||
- All identified issues must be resolved
|
||||
- Project must meet quality and polish standards
|
||||
- Code must be ready for professional presentation
|
||||
- Project meets quality and polish standards based on your assessment
|
||||
- Code is ready for professional presentation
|
||||
- You feel confident showcasing the project on your resume
|
||||
|
||||
## 4. DOCUMENTATION REQUIREMENTS
|
||||
|
||||
### 4.1. Documentation Coaching
|
||||
### 4.1. Self-Guided Documentation
|
||||
|
||||
Programme leadership will provide coaching on writing documentation for the flagship project.
|
||||
Use the provided documentation templates and examples in the resource library to create documentation for your flagship project.
|
||||
|
||||
**Documentation Resources:**
|
||||
- README.md template and examples
|
||||
- CONTRIBUTING.md template and examples
|
||||
- LICENSE.md template and guidance
|
||||
- End user documentation examples
|
||||
|
||||
**Optional Support:**
|
||||
- If you need help with documentation, ask in the #mentee-chat channel
|
||||
- Programme leadership or community members can provide guidance if requested
|
||||
- You can proceed independently using the provided templates
|
||||
|
||||
### 4.2. Required Documentation Files
|
||||
|
||||
**Mandatory Documentation:**
|
||||
Participants must create the following standard documentation files:
|
||||
**Standard Documentation:**
|
||||
You should create the following standard documentation files:
|
||||
|
||||
**4.2.1 README.md:**
|
||||
- Provides a high-level overview of the project
|
||||
- Includes project description, features, and usage instructions
|
||||
- Contains installation and setup instructions
|
||||
- Includes contribution guidelines and project information
|
||||
- Template and examples available in resource library
|
||||
|
||||
**4.2.2 CONTRIBUTING.md:**
|
||||
- Contains instructions for individuals seeking to contribute to the project
|
||||
- Outlines contribution guidelines and procedures
|
||||
- Describes development workflow and standards
|
||||
- Provides information about code review and submission processes
|
||||
- Template and examples available in resource library
|
||||
|
||||
**4.2.3 LICENSE.md:**
|
||||
- Determines what people can and cannot do with the software
|
||||
- Specifies licensing terms and conditions
|
||||
- Must comply with applicable intellectual property requirements
|
||||
- Should align with project goals and organisational policies
|
||||
- Template and guidance available in resource library
|
||||
|
||||
### 4.3. End User Documentation
|
||||
|
||||
**Documentation Approach:**
|
||||
- Programme leadership will help determine an approach for in-depth end user documentation
|
||||
- Documentation approach will be tailored to project type and complexity
|
||||
- End user documentation should be comprehensive and accessible
|
||||
- Review end user documentation examples in the resource library
|
||||
- Determine an approach appropriate for your project type and complexity
|
||||
- Create comprehensive and accessible end user documentation
|
||||
- Ask for feedback in Discord if you'd like guidance (optional)
|
||||
|
||||
## 5. DEPLOYMENT AND HOSTING
|
||||
|
||||
### 5.1. Deployment Requirement
|
||||
|
||||
**Mandatory Requirement:**
|
||||
Participants must deploy a live version of their application.
|
||||
**Deployment Goal:**
|
||||
You should deploy a live version of your application for professional presentation.
|
||||
|
||||
### 5.2. Deployment Consultation
|
||||
### 5.2. Self-Guided Deployment
|
||||
|
||||
**IMPORTANT: Participants MUST consult with programme leadership BEFORE deploying their application.**
|
||||
**Deployment Resources:**
|
||||
- Deployment guides for common platforms (Vercel, Netlify, Heroku, etc.) are available in the resource library
|
||||
- Step-by-step tutorials for various hosting providers
|
||||
- Information about free hosting options
|
||||
- Deployment checklist and troubleshooting guides
|
||||
|
||||
**Consultation Benefits:**
|
||||
- Programme leadership can provide guidance on deployment options
|
||||
- Information about free hosting options may be available
|
||||
- Assistance with deployment pipeline configuration
|
||||
- Recommendations for hosting providers that fit project needs
|
||||
**Deployment Process:**
|
||||
- Review deployment guides in the resource library
|
||||
- Select a hosting provider appropriate for your project
|
||||
- Follow the deployment guide for your chosen platform
|
||||
- Deploy your application independently
|
||||
|
||||
### 5.3. Hosting Provider Selection
|
||||
|
||||
**Selection Process:**
|
||||
- Programme leadership will help identify appropriate hosting providers
|
||||
- Considerations include project requirements, budget, and scalability needs
|
||||
- Free hosting options will be explored when available
|
||||
**Self-Selection Process:**
|
||||
- Review hosting provider options in the deployment guides
|
||||
- Consider project requirements, budget, and scalability needs
|
||||
- Free hosting options are documented in the resource library
|
||||
- Paid hosting options may be necessary depending on project requirements
|
||||
|
||||
### 5.4. Domain Configuration
|
||||
|
||||
**Domain Setup:**
|
||||
- Programme leadership can assist with domain configuration
|
||||
- Domain configuration guides are available in the resource library
|
||||
- Domains generally require payment
|
||||
- Free domain options may be available in some cases
|
||||
- Domain setup is optional but recommended for professional presentation
|
||||
@@ -124,9 +159,14 @@ Participants must deploy a live version of their application.
|
||||
**Cost Considerations:**
|
||||
- Domains generally cost money
|
||||
- Hosting generally costs money
|
||||
- Programme leadership will seek free options when possible
|
||||
- Free hosting options are documented in the resource library
|
||||
- Free options may not always be viable depending on project requirements
|
||||
|
||||
**Optional Support:**
|
||||
- If you encounter issues during deployment, ask for help in the #mentee-chat channel
|
||||
- Programme leadership or community members can provide guidance if requested
|
||||
- Most deployment can be completed independently using the provided guides
|
||||
|
||||
## 6. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
### 6.1. Reference to Comprehensive Liability Framework
|
||||
@@ -138,9 +178,11 @@ Participants must deploy a live version of their application.
|
||||
This Documentation establishes final polish procedures and requirements. However:
|
||||
|
||||
- Programme leadership reserves the right to modify final polish procedures at any time
|
||||
- Final polish is a self-guided process using provided checklists and templates
|
||||
- Final polish does not guarantee specific project outcomes or employment results
|
||||
- Programme leadership is not responsible for participants' ability to complete final polish procedures
|
||||
- Individual results may vary based on participant effort, project complexity, and other factors
|
||||
- Reviews and approvals are optional and available upon request
|
||||
|
||||
### 6.3. Hosting and Deployment Disclaimer
|
||||
|
||||
|
||||
@@ -12,107 +12,172 @@ This Career Preparation Documentation (hereinafter referred to as "the Documenta
|
||||
|
||||
### 1.2. Scope and Applicability
|
||||
|
||||
This Documentation applies to all participants in our Mentorship Programme who are ready to begin their job search. Programme leadership will provide support and assistance with career preparation activities as set forth in this Documentation.
|
||||
This Documentation applies to all participants in our Mentorship Programme who are ready to begin their job search. Career preparation resources and support are available as set forth in this Documentation.
|
||||
|
||||
**IMPORTANT: Career preparation support is provided to assist participants in their job search. Programme leadership does not guarantee employment outcomes or specific job placement results.**
|
||||
**IMPORTANT: This is a self-guided process. You will use provided resources, templates, and guides to prepare for your job search independently. Support is available upon request, but most activities can be completed using the resource library.**
|
||||
|
||||
## 2. CAREER PREPARATION SUPPORT
|
||||
## 2. CAREER PREPARATION RESOURCES
|
||||
|
||||
### 2.1. Support Availability
|
||||
### 2.1. Self-Guided Resources
|
||||
|
||||
Upon reaching the career preparation stage, programme leadership will provide assistance with various aspects of the job search process as outlined in Sections 3 through 6 of this Documentation.
|
||||
Upon reaching the career preparation stage, you have access to comprehensive resources for various aspects of the job search process as outlined in Sections 3 through 6 of this Documentation.
|
||||
|
||||
### 2.2. Support Scope
|
||||
**Resource Library Includes:**
|
||||
- Resume templates and examples
|
||||
- LinkedIn profile optimization guides
|
||||
- Application writing guides and examples
|
||||
- Interview preparation resources
|
||||
- Mock interview question banks
|
||||
- Job search strategy guides
|
||||
|
||||
Programme leadership will continue to provide career preparation support and refine flagship projects until participants achieve employment, subject to programme terms and conditions.
|
||||
### 2.2. Optional Support
|
||||
|
||||
## 3. RESUME REVIEW
|
||||
**On-Demand Assistance:**
|
||||
- Programme leadership and community members are available to provide assistance when requested
|
||||
- Support is provided when available, not guaranteed immediately
|
||||
- You can proceed independently using the provided resources
|
||||
- Most career preparation activities can be completed using the resource library
|
||||
|
||||
### 3.1. Resume Development Support
|
||||
## 3. RESUME DEVELOPMENT
|
||||
|
||||
**Support Provided:**
|
||||
- Programme leadership will work with participants to develop polished resumes/CVs
|
||||
- Resumes will be prepared for distribution to potential employers
|
||||
- Resume content will be reviewed and refined for effectiveness
|
||||
### 3.1. Self-Guided Resume Creation
|
||||
|
||||
**Resources Available:**
|
||||
- Resume templates for various career paths (available in resource library)
|
||||
- Resume examples and best practices guides
|
||||
- Flagship project presentation examples
|
||||
- Resume writing tips and strategies
|
||||
|
||||
**Self-Guided Process:**
|
||||
- Use provided templates and examples to create your resume
|
||||
- Include your flagship project as a demonstration of skills and capabilities
|
||||
- Review resume best practices guides
|
||||
- Refine your resume independently
|
||||
|
||||
### 3.2. Flagship Project Inclusion
|
||||
|
||||
**Mandatory Requirement:**
|
||||
- Resumes must include the flagship project developed during the Mentorship Programme
|
||||
**Important Requirement:**
|
||||
- Your resume should include the flagship project developed during the Mentorship Programme
|
||||
- Flagship project serves as a demonstration of skills and capabilities
|
||||
- Project presentation on resume will be reviewed and refined
|
||||
- Review flagship project presentation examples in the resource library
|
||||
- Present your project effectively on your resume
|
||||
|
||||
**Optional Review:**
|
||||
- If you would like feedback on your resume, request a review in the #mentee-chat channel
|
||||
- Programme leadership or community members can provide feedback if requested
|
||||
- Reviews are optional and available upon request
|
||||
|
||||
## 4. LINKEDIN PROFILE PREPARATION
|
||||
|
||||
### 4.1. LinkedIn Profile Support
|
||||
### 4.1. Self-Guided Profile Optimization
|
||||
|
||||
**Support Provided:**
|
||||
- Programme leadership will assist in curating LinkedIn profiles
|
||||
- Profile optimisation to help participants stand out
|
||||
- Strategic positioning for career success
|
||||
- Content review and refinement
|
||||
**Resources Available:**
|
||||
- LinkedIn profile optimization guides (available in resource library)
|
||||
- Profile examples and best practices
|
||||
- Content templates and suggestions
|
||||
- Strategic positioning strategies
|
||||
|
||||
### 4.2. Profile Optimization
|
||||
**Self-Guided Process:**
|
||||
- Review LinkedIn optimization guides in the resource library
|
||||
- Optimize your profile to help you stand out
|
||||
- Strategically position yourself for career success
|
||||
- Showcase your flagship project and achievements
|
||||
|
||||
LinkedIn profile preparation focuses on:
|
||||
### 4.2. Profile Optimization Focus Areas
|
||||
|
||||
LinkedIn profile preparation should focus on:
|
||||
- Professional presentation and branding
|
||||
- Highlighting relevant skills and experience
|
||||
- Showcasing flagship project and achievements
|
||||
- Optimizing profile for recruiter visibility
|
||||
|
||||
**Optional Review:**
|
||||
- If you would like feedback on your LinkedIn profile, request a review in the #mentee-chat channel
|
||||
- Programme leadership or community members can provide feedback if requested
|
||||
- Reviews are optional and available upon request
|
||||
|
||||
## 5. APPLICATION ASSISTANCE
|
||||
|
||||
### 5.1. Job Search Support
|
||||
### 5.1. Job Search Resources
|
||||
|
||||
**Support Provided:**
|
||||
- Programme leadership will help refine job search strategies
|
||||
- Assistance with identifying appropriate job opportunities
|
||||
- Guidance on application processes and requirements
|
||||
**Resources Available:**
|
||||
- Job search strategy guides (available in resource library)
|
||||
- Job board recommendations and resources
|
||||
- Application process guides
|
||||
- Application writing tips and examples
|
||||
|
||||
### 5.2. Application Content Assistance
|
||||
**Self-Guided Process:**
|
||||
- Review job search strategy guides in the resource library
|
||||
- Identify appropriate job opportunities independently
|
||||
- Use application guides and examples to craft effective applications
|
||||
- Submit applications independently
|
||||
|
||||
**Support Scope:**
|
||||
- Programme leadership will help participants determine what to say in applications
|
||||
- Assistance with crafting effective application materials
|
||||
- Review and feedback on application content
|
||||
### 5.2. Application Content Resources
|
||||
|
||||
**Limitations:**
|
||||
- Programme leadership cannot and will not complete job applications on behalf of participants
|
||||
- Participants are responsible for submitting their own applications
|
||||
**Resources Available:**
|
||||
- Application writing guides and examples (available in resource library)
|
||||
- Cover letter templates and examples
|
||||
- Application content tips and strategies
|
||||
- Common application question examples
|
||||
|
||||
**Self-Guided Process:**
|
||||
- Use provided guides and examples to determine what to say in applications
|
||||
- Craft effective application materials independently
|
||||
- Review application content using provided checklists
|
||||
|
||||
**Optional Support:**
|
||||
- If you would like feedback on your applications, request a review in the #mentee-chat channel
|
||||
- Programme leadership or community members can provide feedback if requested
|
||||
- Support is limited to guidance and feedback on application content
|
||||
- You are responsible for submitting your own applications
|
||||
|
||||
## 6. MOCK INTERVIEWS
|
||||
## 6. INTERVIEW PREPARATION
|
||||
|
||||
### 6.1. Interview Preparation
|
||||
### 6.1. Self-Guided Interview Preparation
|
||||
|
||||
**Support Provided:**
|
||||
- Programme leadership will conduct mock interviews with participants
|
||||
- Mock interviews prepare participants for real interview situations
|
||||
- Feedback and coaching on interview performance
|
||||
- Practice with common interview questions and scenarios
|
||||
**Resources Available:**
|
||||
- Interview preparation guides (available in resource library)
|
||||
- Common interview question banks
|
||||
- Mock interview question sets
|
||||
- Interview best practices and tips
|
||||
- Behavioural interview guides
|
||||
- Technical interview preparation resources
|
||||
|
||||
### 6.2. Interview Timing
|
||||
**Self-Guided Process:**
|
||||
- Review interview preparation guides in the resource library
|
||||
- Practice with common interview questions independently
|
||||
- Use mock interview question sets for practice
|
||||
- Prepare for real interview scenarios
|
||||
|
||||
**Initiation:**
|
||||
- Mock interviews begin once participants start landing actual interviews
|
||||
- Preparation focuses on real interview scenarios participants will face
|
||||
- Ongoing support as participants progress through interview processes
|
||||
### 6.2. Optional Mock Interviews
|
||||
|
||||
## 7. CONTINUOUS SUPPORT
|
||||
**Mock Interview Availability:**
|
||||
- Mock interviews are available upon request when programme leadership or community members are available
|
||||
- Request mock interviews in the #mentee-chat channel
|
||||
- Mock interviews prepare you for real interview situations
|
||||
- Feedback and coaching on interview performance may be provided
|
||||
|
||||
### 7.1. Ongoing Assistance
|
||||
**Timing:**
|
||||
- Begin interview preparation when you start applying for jobs
|
||||
- Request mock interviews when you start landing actual interviews
|
||||
- Preparation should focus on real interview scenarios you will face
|
||||
|
||||
**Support Continuity:**
|
||||
- Programme leadership will continue providing all career preparation support
|
||||
- Flagship project refinement and iteration will continue
|
||||
- Support continues until participants achieve employment
|
||||
## 7. CONTINUOUS RESOURCES AND SUPPORT
|
||||
|
||||
### 7.1. Ongoing Resources
|
||||
|
||||
**Resource Availability:**
|
||||
- Career preparation resources remain available throughout your job search
|
||||
- Flagship project can be refined and iterated independently
|
||||
- Resources and support continue to be available as needed
|
||||
|
||||
### 7.2. Goal Achievement
|
||||
|
||||
**Programme Focus:**
|
||||
- Programme leadership works with participants until they achieve employment
|
||||
- Combination of career preparation activities and project refinement
|
||||
- Goal is to help participants reach their career objectives
|
||||
- Programme resources and optional support are available to help you achieve employment
|
||||
- Combination of self-guided career preparation activities and project refinement
|
||||
- Goal is to help you reach your career objectives
|
||||
- You work at your own pace using provided resources
|
||||
|
||||
## 8. LIMITATION OF LIABILITY AND DISCLAIMERS
|
||||
|
||||
@@ -122,12 +187,14 @@ LinkedIn profile preparation focuses on:
|
||||
|
||||
### 8.2. Career Preparation Disclaimer
|
||||
|
||||
This Documentation establishes career preparation procedures and support. However:
|
||||
This Documentation establishes career preparation procedures and resources. However:
|
||||
|
||||
- Programme leadership reserves the right to modify career preparation procedures at any time
|
||||
- Career preparation support does not guarantee employment outcomes
|
||||
- Career preparation is primarily self-guided using provided resources
|
||||
- Career preparation resources and support do not guarantee employment outcomes
|
||||
- Programme leadership is not responsible for participants' ability to secure employment
|
||||
- Individual results may vary based on participant effort, market conditions, and other factors
|
||||
- Support is provided when requested and available, not guaranteed immediately
|
||||
|
||||
### 8.3. Employment Outcome Disclaimer
|
||||
|
||||
|
||||
@@ -0,0 +1,313 @@
|
||||
---
|
||||
title: Career Preparation Resources
|
||||
---
|
||||
|
||||
**RESUME TEMPLATES, LINKEDIN GUIDES, APPLICATION GUIDES, INTERVIEW RESOURCES, AND JOB SEARCH STRATEGIES**
|
||||
|
||||
## Resume Templates
|
||||
|
||||
### Developer Resume Template
|
||||
|
||||
```markdown
|
||||
[Your Name]
|
||||
[Email] | [Phone] | [LinkedIn] | [GitHub] | [Portfolio]
|
||||
|
||||
## Summary
|
||||
[2-3 sentences describing your experience, skills, and career goals]
|
||||
|
||||
## Technical Skills
|
||||
- **Languages:** [List languages]
|
||||
- **Frameworks/Libraries:** [List frameworks]
|
||||
- **Tools:** [List tools]
|
||||
- **Databases:** [List databases]
|
||||
- **Other:** [List other relevant skills]
|
||||
|
||||
## Projects
|
||||
|
||||
### [Project Name]
|
||||
[Brief description] | [Technologies Used] | [GitHub Link] | [Live Demo]
|
||||
- [Key achievement or feature]
|
||||
- [Key achievement or feature]
|
||||
|
||||
### [Project Name]
|
||||
[Brief description] | [Technologies Used] | [GitHub Link] | [Live Demo]
|
||||
- [Key achievement or feature]
|
||||
- [Key achievement or feature]
|
||||
|
||||
## Experience (if applicable)
|
||||
|
||||
### [Job Title]
|
||||
[Company Name] | [Dates]
|
||||
- [Achievement or responsibility]
|
||||
- [Achievement or responsibility]
|
||||
|
||||
## Education
|
||||
|
||||
[Degree] in [Field]
|
||||
[Institution] | [Dates]
|
||||
- [Relevant coursework or achievement]
|
||||
|
||||
## Additional Information
|
||||
- [Certifications, awards, or other relevant information]
|
||||
```
|
||||
|
||||
### Resume Best Practices
|
||||
|
||||
**Formatting:**
|
||||
- Keep it to 1-2 pages
|
||||
- Use clear, readable fonts
|
||||
- Use consistent formatting
|
||||
- Save as PDF for applications
|
||||
|
||||
**Content:**
|
||||
- Tailor resume to each job
|
||||
- Use action verbs
|
||||
- Quantify achievements when possible
|
||||
- Highlight relevant skills and projects
|
||||
- Include links to GitHub and portfolio
|
||||
|
||||
**Flagship Project:**
|
||||
- Include your mentorship programme flagship project
|
||||
- Describe technologies used
|
||||
- Highlight key features
|
||||
- Include links to code and live demo
|
||||
|
||||
## LinkedIn Profile Optimization
|
||||
|
||||
### Profile Sections
|
||||
|
||||
**Headline:**
|
||||
- Include your role/title
|
||||
- Mention key technologies
|
||||
- Keep it concise and professional
|
||||
- Example: "Full-Stack Developer | React, Node.js, TypeScript"
|
||||
|
||||
**Summary:**
|
||||
- Write in first person
|
||||
- Highlight your skills and experience
|
||||
- Mention your career goals
|
||||
- Include relevant keywords
|
||||
- Keep it engaging and authentic
|
||||
|
||||
**Experience:**
|
||||
- List relevant work experience
|
||||
- Use bullet points for achievements
|
||||
- Quantify results when possible
|
||||
- Include technologies used
|
||||
|
||||
**Projects:**
|
||||
- Add your flagship project
|
||||
- Include project descriptions
|
||||
- Link to GitHub and live demos
|
||||
- Highlight technologies and achievements
|
||||
|
||||
**Skills:**
|
||||
- Add relevant technical skills
|
||||
- Get endorsements from connections
|
||||
- Keep skills up to date
|
||||
- Remove outdated skills
|
||||
|
||||
**Recommendations:**
|
||||
- Request recommendations from mentors, colleagues, or collaborators
|
||||
- Provide recommendations for others
|
||||
- Keep recommendations relevant and recent
|
||||
|
||||
### LinkedIn Best Practices
|
||||
|
||||
**Profile:**
|
||||
- Use professional profile photo
|
||||
- Customize your LinkedIn URL
|
||||
- Keep profile updated
|
||||
- Engage with content regularly
|
||||
|
||||
**Networking:**
|
||||
- Connect with industry professionals
|
||||
- Join relevant groups
|
||||
- Engage with posts and discussions
|
||||
- Share your own content
|
||||
|
||||
**Content:**
|
||||
- Share project updates
|
||||
- Write articles about your learning journey
|
||||
- Comment on others' posts
|
||||
- Build your professional brand
|
||||
|
||||
## Application Writing Guides
|
||||
|
||||
### Cover Letter Template
|
||||
|
||||
```markdown
|
||||
[Your Name]
|
||||
[Email] | [Phone] | [LinkedIn]
|
||||
|
||||
[Date]
|
||||
|
||||
[Hiring Manager Name]
|
||||
[Company Name]
|
||||
[Company Address]
|
||||
|
||||
Dear [Hiring Manager Name],
|
||||
|
||||
I am writing to express my interest in the [Position Title] position at [Company Name]. [1-2 sentences about why you're interested in the company/role].
|
||||
|
||||
[Paragraph about your relevant experience and skills, specifically mentioning your flagship project and technologies used].
|
||||
|
||||
[Paragraph about what you can contribute to the company and why you're a good fit].
|
||||
|
||||
I am excited about the opportunity to contribute to [Company Name] and would welcome the chance to discuss how my skills and experience align with your needs.
|
||||
|
||||
Thank you for your consideration.
|
||||
|
||||
Sincerely,
|
||||
[Your Name]
|
||||
```
|
||||
|
||||
### Application Best Practices
|
||||
|
||||
**Tailoring:**
|
||||
- Customize each application
|
||||
- Match keywords from job description
|
||||
- Highlight relevant experience
|
||||
- Show enthusiasm for the role
|
||||
|
||||
**Research:**
|
||||
- Research the company
|
||||
- Understand the role
|
||||
- Learn about company culture
|
||||
- Find connections at the company
|
||||
|
||||
**Follow-Up:**
|
||||
- Send thank-you emails after interviews
|
||||
- Follow up if you don't hear back
|
||||
- Be professional and respectful
|
||||
- Don't be pushy
|
||||
|
||||
## Interview Preparation Resources
|
||||
|
||||
### Common Interview Questions
|
||||
|
||||
**Technical Questions:**
|
||||
- Explain [technology/concept]
|
||||
- How would you implement [feature]?
|
||||
- What's the difference between [X] and [Y]?
|
||||
- How do you handle [scenario]?
|
||||
|
||||
**Behavioural Questions:**
|
||||
- Tell me about yourself
|
||||
- Why do you want to work here?
|
||||
- Describe a challenging project
|
||||
- How do you handle conflict?
|
||||
- Where do you see yourself in 5 years?
|
||||
|
||||
**Project Questions:**
|
||||
- Walk me through your flagship project
|
||||
- What challenges did you face?
|
||||
- What would you do differently?
|
||||
- How did you approach [specific aspect]?
|
||||
|
||||
### Interview Preparation Tips
|
||||
|
||||
**Before the Interview:**
|
||||
- Research the company and role
|
||||
- Review your resume and projects
|
||||
- Prepare questions to ask
|
||||
- Practice common questions
|
||||
- Prepare examples of your work
|
||||
|
||||
**During the Interview:**
|
||||
- Be confident and authentic
|
||||
- Listen carefully to questions
|
||||
- Think before answering
|
||||
- Ask clarifying questions
|
||||
- Show enthusiasm
|
||||
|
||||
**After the Interview:**
|
||||
- Send thank-you email
|
||||
- Reflect on the experience
|
||||
- Follow up if appropriate
|
||||
- Continue applying to other positions
|
||||
|
||||
### Mock Interview Questions
|
||||
|
||||
**Technical:**
|
||||
- Explain how the internet works
|
||||
- What is REST?
|
||||
- Explain authentication vs authorization
|
||||
- How do you debug code?
|
||||
- What is your approach to testing?
|
||||
|
||||
**Behavioural:**
|
||||
- Tell me about a time you overcame a challenge
|
||||
- Describe a project you're proud of
|
||||
- How do you handle tight deadlines?
|
||||
- Tell me about a time you worked in a team
|
||||
- How do you stay current with technology?
|
||||
|
||||
## Job Search Strategy Guides
|
||||
|
||||
### Job Search Platforms
|
||||
|
||||
**General Platforms:**
|
||||
- LinkedIn Jobs
|
||||
- Indeed
|
||||
- Glassdoor
|
||||
- Monster
|
||||
- ZipRecruiter
|
||||
|
||||
**Tech-Specific Platforms:**
|
||||
- GitHub Jobs
|
||||
- Stack Overflow Jobs
|
||||
- AngelList
|
||||
- Hacker News "Who's Hiring"
|
||||
- Remote-specific: Remote.co, We Work Remotely
|
||||
|
||||
### Job Search Strategy
|
||||
|
||||
**Networking:**
|
||||
- Attend meetups and conferences
|
||||
- Join online communities
|
||||
- Connect with industry professionals
|
||||
- Reach out to people at target companies
|
||||
|
||||
**Application Strategy:**
|
||||
- Apply to multiple positions
|
||||
- Tailor each application
|
||||
- Follow up appropriately
|
||||
- Track your applications
|
||||
|
||||
**Portfolio:**
|
||||
- Keep portfolio updated
|
||||
- Showcase your best work
|
||||
- Include your flagship project
|
||||
- Make it easy to navigate
|
||||
|
||||
**Continuous Learning:**
|
||||
- Keep learning new technologies
|
||||
- Build new projects
|
||||
- Contribute to open source
|
||||
- Stay current with industry trends
|
||||
|
||||
### Job Search Timeline
|
||||
|
||||
**Week 1-2:**
|
||||
- Update resume and LinkedIn
|
||||
- Prepare portfolio
|
||||
- Research target companies
|
||||
- Start applying
|
||||
|
||||
**Week 3-4:**
|
||||
- Continue applying
|
||||
- Network actively
|
||||
- Prepare for interviews
|
||||
- Practice interview questions
|
||||
|
||||
**Ongoing:**
|
||||
- Maintain application pipeline
|
||||
- Continue learning
|
||||
- Build new projects
|
||||
- Stay positive and persistent
|
||||
|
||||
---
|
||||
|
||||
*Career preparation is an ongoing process. Use these resources to build a strong professional presence and prepare for job opportunities.*
|
||||
|
||||
@@ -0,0 +1,197 @@
|
||||
---
|
||||
title: Code Development Resources
|
||||
---
|
||||
|
||||
**CODE REVIEW CHECKLIST, SELF-REVIEW GUIDELINES, AND BEST PRACTICES**
|
||||
|
||||
## Code Review Checklist
|
||||
|
||||
See [Code Review Checklist](/mentorship/resources/code-review-checklist) for the comprehensive self-review checklist.
|
||||
|
||||
## Self-Review Guidelines
|
||||
|
||||
### Before Requesting a Review
|
||||
|
||||
**Self-Review Process:**
|
||||
1. Review your code against the checklist
|
||||
2. Run all tests and ensure they pass
|
||||
3. Check for obvious bugs or issues
|
||||
4. Ensure code follows style guide
|
||||
5. Verify functionality works as expected
|
||||
6. Check for security concerns
|
||||
7. Review documentation and comments
|
||||
|
||||
### Self-Review Questions
|
||||
|
||||
**Code Quality:**
|
||||
- Is my code readable and well-organized?
|
||||
- Are variable and function names clear?
|
||||
- Is the code properly commented?
|
||||
- Does the code follow project conventions?
|
||||
|
||||
**Functionality:**
|
||||
- Does the code work as intended?
|
||||
- Are edge cases handled?
|
||||
- Is error handling appropriate?
|
||||
- Is input validation in place?
|
||||
|
||||
**Testing:**
|
||||
- Are tests written and passing?
|
||||
- Is test coverage adequate?
|
||||
- Do tests actually test behavior?
|
||||
|
||||
**Security:**
|
||||
- Is sensitive data protected?
|
||||
- Is input validated and sanitized?
|
||||
- Are authentication/authorization checks in place?
|
||||
|
||||
## Development Best Practices
|
||||
|
||||
### Code Quality
|
||||
|
||||
**Readability:**
|
||||
- Use clear, descriptive names
|
||||
- Keep functions focused and small
|
||||
- Write self-documenting code
|
||||
- Add comments for complex logic
|
||||
|
||||
**Organization:**
|
||||
- Follow project structure conventions
|
||||
- Group related code together
|
||||
- Separate concerns appropriately
|
||||
- Use consistent formatting
|
||||
|
||||
**Maintainability:**
|
||||
- Write code that's easy to modify
|
||||
- Avoid unnecessary complexity
|
||||
- Follow DRY (Don't Repeat Yourself)
|
||||
- Refactor when needed
|
||||
|
||||
### Git Practices
|
||||
|
||||
**Commit Messages:**
|
||||
- Write clear, descriptive commit messages
|
||||
- Use present tense ("Add feature" not "Added feature")
|
||||
- Reference issue numbers when applicable
|
||||
- Keep commits focused and atomic
|
||||
|
||||
**Branching:**
|
||||
- Create branches for each feature/user story
|
||||
- Use descriptive branch names
|
||||
- Keep branches up to date
|
||||
- Clean up merged branches
|
||||
|
||||
**Pull Requests:**
|
||||
- Write clear PR descriptions
|
||||
- Link related issues
|
||||
- Keep PRs focused and reasonably sized
|
||||
- Request reviews when needed
|
||||
|
||||
### Testing
|
||||
|
||||
**Test Coverage:**
|
||||
- Write tests for new functionality
|
||||
- Test edge cases and error scenarios
|
||||
- Maintain good test coverage
|
||||
- Keep tests maintainable
|
||||
|
||||
**Test Types:**
|
||||
- **Unit Tests:** Test individual functions/methods
|
||||
- **Integration Tests:** Test component interactions
|
||||
- **E2E Tests:** Test user workflows (if applicable)
|
||||
|
||||
### Security
|
||||
|
||||
**Best Practices:**
|
||||
- Never commit secrets or sensitive data
|
||||
- Use environment variables for configuration
|
||||
- Validate and sanitize all user input
|
||||
- Implement proper authentication/authorization
|
||||
- Keep dependencies up to date
|
||||
- Follow security best practices for your stack
|
||||
|
||||
### Performance
|
||||
|
||||
**Optimization:**
|
||||
- Profile before optimizing
|
||||
- Optimize database queries
|
||||
- Minimize API calls
|
||||
- Use caching where appropriate
|
||||
- Optimize assets (images, CSS, JS)
|
||||
|
||||
### Documentation
|
||||
|
||||
**Code Documentation:**
|
||||
- Comment complex logic
|
||||
- Document function parameters and returns
|
||||
- Keep comments up to date
|
||||
- Write self-documenting code when possible
|
||||
|
||||
**Project Documentation:**
|
||||
- Keep README updated
|
||||
- Document setup and installation
|
||||
- Document API endpoints (if applicable)
|
||||
- Document deployment process
|
||||
|
||||
## Common Pitfalls to Avoid
|
||||
|
||||
### Code Quality Issues
|
||||
|
||||
❌ **Overly complex code:** Keep it simple
|
||||
❌ **Poor naming:** Use descriptive names
|
||||
❌ **Large functions:** Break them down
|
||||
❌ **Code duplication:** Refactor to DRY
|
||||
❌ **Commented-out code:** Remove it
|
||||
|
||||
### Git Issues
|
||||
|
||||
❌ **Vague commit messages:** Be specific
|
||||
❌ **Large commits:** Make smaller, focused commits
|
||||
❌ **Mixing concerns:** One concern per commit
|
||||
❌ **Forgetting to pull:** Keep branches updated
|
||||
|
||||
### Testing Issues
|
||||
|
||||
❌ **No tests:** Always write tests
|
||||
❌ **Weak tests:** Test actual behavior
|
||||
❌ **Ignoring failing tests:** Fix them
|
||||
❌ **Testing implementation:** Test behavior
|
||||
|
||||
### Security Issues
|
||||
|
||||
❌ **Hardcoded secrets:** Use environment variables
|
||||
❌ **No input validation:** Always validate
|
||||
❌ **Outdated dependencies:** Keep updated
|
||||
❌ **Ignoring security warnings:** Address them
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Daily Workflow
|
||||
|
||||
1. **Pull latest changes** from main branch
|
||||
2. **Create feature branch** for your work
|
||||
3. **Write code** following best practices
|
||||
4. **Write tests** for new functionality
|
||||
5. **Run tests** and ensure they pass
|
||||
6. **Self-review** your code
|
||||
7. **Commit changes** with clear messages
|
||||
8. **Push to remote** regularly
|
||||
9. **Create PR** when feature is complete
|
||||
10. **Request review** if desired (optional)
|
||||
|
||||
### Feature Development
|
||||
|
||||
1. **Understand requirements** from user story
|
||||
2. **Review technical breakdown** if available
|
||||
3. **Plan implementation** approach
|
||||
4. **Set up** necessary components/modules
|
||||
5. **Implement** feature incrementally
|
||||
6. **Test** as you go
|
||||
7. **Refactor** when needed
|
||||
8. **Document** as appropriate
|
||||
9. **Review** before submitting
|
||||
|
||||
---
|
||||
|
||||
*Following best practices helps you write better code, work more efficiently, and maintain high quality standards.*
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: Code Review Checklist
|
||||
---
|
||||
|
||||
**SELF-REVIEW CHECKLIST FOR CODE QUALITY**
|
||||
|
||||
Use this checklist to review your own code before merging pull requests or when preparing for optional code reviews.
|
||||
|
||||
## Code Quality
|
||||
|
||||
- [ ] Code follows project style guide and conventions
|
||||
- [ ] Code is readable and well-organized
|
||||
- [ ] Variable and function names are clear and descriptive
|
||||
- [ ] Code is properly commented where necessary
|
||||
- [ ] No commented-out code or debugging statements left in
|
||||
- [ ] Code follows DRY (Don't Repeat Yourself) principles
|
||||
- [ ] Functions and methods are appropriately sized and focused
|
||||
|
||||
## Functionality
|
||||
|
||||
- [ ] Code implements the intended feature correctly
|
||||
- [ ] Edge cases are handled appropriately
|
||||
- [ ] Error handling is implemented where needed
|
||||
- [ ] User input is validated and sanitized
|
||||
- [ ] Code handles null/undefined values appropriately
|
||||
|
||||
## Testing
|
||||
|
||||
- [ ] Unit tests are written and passing
|
||||
- [ ] Integration tests are written and passing (if applicable)
|
||||
- [ ] Test coverage is adequate for new functionality
|
||||
- [ ] Tests are meaningful and test actual behavior
|
||||
- [ ] All tests pass before submitting
|
||||
|
||||
## Security
|
||||
|
||||
- [ ] No sensitive data is hardcoded or exposed
|
||||
- [ ] Authentication and authorization are properly implemented (if applicable)
|
||||
- [ ] Input validation prevents injection attacks
|
||||
- [ ] Dependencies are up to date and secure
|
||||
- [ ] Security best practices are followed
|
||||
|
||||
## Performance
|
||||
|
||||
- [ ] Code performs efficiently
|
||||
- [ ] No obvious performance bottlenecks
|
||||
- [ ] Database queries are optimized (if applicable)
|
||||
- [ ] Unnecessary computations are avoided
|
||||
|
||||
## Documentation
|
||||
|
||||
- [ ] Code is self-documenting with clear naming
|
||||
- [ ] Complex logic is explained with comments
|
||||
- [ ] README is updated if needed
|
||||
- [ ] API documentation is updated if applicable
|
||||
|
||||
## Git Practices
|
||||
|
||||
- [ ] Commit messages are clear and descriptive
|
||||
- [ ] Commits are appropriately sized
|
||||
- [ ] Branch name follows naming conventions
|
||||
- [ ] Pull request description explains changes clearly
|
||||
- [ ] Related issues are linked in PR description
|
||||
|
||||
## Accessibility (if applicable)
|
||||
|
||||
- [ ] UI components are accessible
|
||||
- [ ] ARIA labels are used where appropriate
|
||||
- [ ] Keyboard navigation works
|
||||
- [ ] Screen reader compatibility is considered
|
||||
|
||||
## Browser/Platform Compatibility (if applicable)
|
||||
|
||||
- [ ] Code works across target browsers/platforms
|
||||
- [ ] Responsive design is implemented (if applicable)
|
||||
- [ ] Cross-browser testing is done (if applicable)
|
||||
|
||||
---
|
||||
|
||||
*This checklist is a starting point. Customize it based on your project's specific requirements and standards.*
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Final Polish Checklist
|
||||
---
|
||||
|
||||
**COMPREHENSIVE CHECKLIST FOR PROJECT FINAL POLISH**
|
||||
|
||||
Use this checklist to ensure your flagship project is ready for professional presentation.
|
||||
|
||||
## Code Quality
|
||||
|
||||
- [ ] All code follows project style guide
|
||||
- [ ] Code is clean, readable, and well-organized
|
||||
- [ ] No commented-out code or debugging statements
|
||||
- [ ] Error handling is comprehensive
|
||||
- [ ] Code is properly commented where necessary
|
||||
- [ ] All functions and methods are appropriately sized
|
||||
|
||||
## Testing
|
||||
|
||||
- [ ] Comprehensive test coverage
|
||||
- [ ] All tests are passing
|
||||
- [ ] Tests are meaningful and test actual behavior
|
||||
- [ ] Edge cases are covered by tests
|
||||
- [ ] CI/CD pipeline is configured and passing
|
||||
|
||||
## Documentation
|
||||
|
||||
- [ ] README.md is complete and professional
|
||||
- [ ] Project description
|
||||
- [ ] Features list
|
||||
- [ ] Installation instructions
|
||||
- [ ] Usage instructions
|
||||
- [ ] Screenshots or demo links (if applicable)
|
||||
- [ ] Technology stack
|
||||
- [ ] Contributing guidelines link
|
||||
- [ ] CONTRIBUTING.md is complete
|
||||
- [ ] Development setup instructions
|
||||
- [ ] Code style guidelines
|
||||
- [ ] Pull request process
|
||||
- [ ] Testing requirements
|
||||
- [ ] LICENSE.md is present and appropriate
|
||||
- [ ] Code comments are clear and helpful
|
||||
- [ ] API documentation is complete (if applicable)
|
||||
|
||||
## Security
|
||||
|
||||
- [ ] No sensitive data in code or configuration
|
||||
- [ ] Environment variables are used for secrets
|
||||
- [ ] Dependencies are up to date
|
||||
- [ ] Security best practices are followed
|
||||
- [ ] Authentication/authorization is properly implemented (if applicable)
|
||||
|
||||
## Deployment
|
||||
|
||||
- [ ] Application is deployed and live
|
||||
- [ ] Deployment is automated (CI/CD)
|
||||
- [ ] Environment variables are properly configured
|
||||
- [ ] Application is accessible and functional
|
||||
- [ ] Domain is configured (optional but recommended)
|
||||
|
||||
## User Experience (if applicable)
|
||||
|
||||
- [ ] Application is intuitive and easy to use
|
||||
- [ ] Error messages are clear and helpful
|
||||
- [ ] Loading states are handled appropriately
|
||||
- [ ] Responsive design works on all screen sizes
|
||||
- [ ] Accessibility standards are met
|
||||
|
||||
## Performance
|
||||
|
||||
- [ ] Application loads quickly
|
||||
- [ ] No obvious performance bottlenecks
|
||||
- [ ] Database queries are optimized (if applicable)
|
||||
- [ ] Images and assets are optimized
|
||||
- [ ] Caching is implemented where appropriate
|
||||
|
||||
## Project Organization
|
||||
|
||||
- [ ] Repository structure is clean and logical
|
||||
- [ ] Files are properly organized
|
||||
- [ ] Git history is clean and meaningful
|
||||
- [ ] Issues are properly labeled and organized
|
||||
- [ ] Project board is organized (if used)
|
||||
|
||||
## Professional Presentation
|
||||
|
||||
- [ ] Project can be confidently shown on resume
|
||||
- [ ] Project demonstrates relevant skills
|
||||
- [ ] Project solves a real problem or demonstrates capability
|
||||
- [ ] Code quality reflects professional standards
|
||||
- [ ] Documentation is professional and complete
|
||||
|
||||
## Final Review
|
||||
|
||||
- [ ] All checklist items are completed
|
||||
- [ ] Project is ready for portfolio/resume presentation
|
||||
- [ ] You feel confident showcasing this project
|
||||
- [ ] Optional: Request feedback from community or programme leadership
|
||||
|
||||
---
|
||||
|
||||
*This checklist is comprehensive. Work through it systematically to ensure your project is polished and professional.*
|
||||
|
||||
@@ -0,0 +1,273 @@
|
||||
---
|
||||
title: Final Polish Resources
|
||||
---
|
||||
|
||||
**FINAL POLISH CHECKLIST, CODE CLEANUP GUIDELINES, DOCUMENTATION TEMPLATES, AND DEPLOYMENT GUIDES**
|
||||
|
||||
## Final Polish Checklist
|
||||
|
||||
See [Final Polish Checklist](/mentorship/resources/final-polish-checklist) for the comprehensive checklist.
|
||||
|
||||
## Code Cleanup Guidelines
|
||||
|
||||
### Code Review and Refactoring
|
||||
|
||||
**Review Your Code:**
|
||||
- Remove commented-out code
|
||||
- Remove debugging statements
|
||||
- Remove unused imports/variables
|
||||
- Simplify complex logic
|
||||
- Improve variable/function names
|
||||
- Add missing comments
|
||||
- Fix code style inconsistencies
|
||||
|
||||
### Code Organization
|
||||
|
||||
**Structure:**
|
||||
- Organize files logically
|
||||
- Group related functionality
|
||||
- Separate concerns appropriately
|
||||
- Follow project conventions
|
||||
- Remove duplicate code
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
**Optimize:**
|
||||
- Database queries
|
||||
- API calls
|
||||
- Asset loading
|
||||
- Rendering performance
|
||||
- Memory usage
|
||||
|
||||
### Error Handling
|
||||
|
||||
**Improve:**
|
||||
- Add comprehensive error handling
|
||||
- Provide meaningful error messages
|
||||
- Handle edge cases
|
||||
- Add validation where needed
|
||||
- Improve user feedback
|
||||
|
||||
## Documentation Templates
|
||||
|
||||
### README.md Template
|
||||
|
||||
```markdown
|
||||
# [Project Name]
|
||||
|
||||
[Brief description of what the project does]
|
||||
|
||||
## Features
|
||||
|
||||
- Feature 1
|
||||
- Feature 2
|
||||
- Feature 3
|
||||
|
||||
## Technologies Used
|
||||
|
||||
- Technology 1
|
||||
- Technology 2
|
||||
- Technology 3
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Prerequisite 1
|
||||
- Prerequisite 2
|
||||
|
||||
### Installation
|
||||
|
||||
\`\`\`bash
|
||||
# Installation steps
|
||||
npm install
|
||||
\`\`\`
|
||||
|
||||
### Usage
|
||||
|
||||
\`\`\`bash
|
||||
# Usage instructions
|
||||
npm start
|
||||
\`\`\`
|
||||
|
||||
## Project Structure
|
||||
|
||||
\`\`\`
|
||||
project/
|
||||
├── src/
|
||||
├── tests/
|
||||
└── docs/
|
||||
\`\`\`
|
||||
|
||||
## Contributing
|
||||
|
||||
See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution guidelines.
|
||||
|
||||
## License
|
||||
|
||||
See [LICENSE.md](LICENSE.md) for license information.
|
||||
|
||||
## Contact
|
||||
|
||||
[Your contact information]
|
||||
```
|
||||
|
||||
### CONTRIBUTING.md Template
|
||||
|
||||
```markdown
|
||||
# Contributing to [Project Name]
|
||||
|
||||
Thank you for your interest in contributing!
|
||||
|
||||
## Development Setup
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Prerequisite 1
|
||||
- Prerequisite 2
|
||||
|
||||
### Setup Steps
|
||||
|
||||
1. Fork the repository
|
||||
2. Clone your fork
|
||||
3. Install dependencies
|
||||
4. Create a branch for your changes
|
||||
|
||||
## Code Style
|
||||
|
||||
- Follow project style guide
|
||||
- Use consistent formatting
|
||||
- Write clear, readable code
|
||||
|
||||
## Testing
|
||||
|
||||
- Write tests for new features
|
||||
- Ensure all tests pass
|
||||
- Maintain test coverage
|
||||
|
||||
## Pull Request Process
|
||||
|
||||
1. Create a feature branch
|
||||
2. Make your changes
|
||||
3. Write/update tests
|
||||
4. Update documentation
|
||||
5. Submit pull request
|
||||
6. Address review feedback
|
||||
|
||||
## Questions?
|
||||
|
||||
[Contact information or link to discussions]
|
||||
```
|
||||
|
||||
### LICENSE.md Template
|
||||
|
||||
**Common Licenses:**
|
||||
- **MIT License:** Permissive, allows commercial use
|
||||
- **Apache 2.0:** Permissive with patent protection
|
||||
- **GPL v3:** Copyleft, requires derivative works to be open source
|
||||
- **BSD 3-Clause:** Permissive with attribution requirement
|
||||
|
||||
**Choose a license appropriate for your project.** You can find license templates at [choosealicense.com](https://choosealicense.com/).
|
||||
|
||||
## Deployment Guides
|
||||
|
||||
### Vercel Deployment (Front-End)
|
||||
|
||||
**Steps:**
|
||||
1. Create account at [vercel.com](https://vercel.com)
|
||||
2. Import your GitHub repository
|
||||
3. Configure build settings
|
||||
4. Add environment variables
|
||||
5. Deploy
|
||||
|
||||
**Configuration:**
|
||||
- Build command: `npm run build`
|
||||
- Output directory: `dist` or `build`
|
||||
- Install command: `npm install`
|
||||
|
||||
### Netlify Deployment (Front-End)
|
||||
|
||||
**Steps:**
|
||||
1. Create account at [netlify.com](https://netlify.com)
|
||||
2. Import your GitHub repository
|
||||
3. Configure build settings
|
||||
4. Add environment variables
|
||||
5. Deploy
|
||||
|
||||
**Configuration:**
|
||||
- Build command: `npm run build`
|
||||
- Publish directory: `dist` or `build`
|
||||
|
||||
### Railway Deployment (Back-End)
|
||||
|
||||
**Steps:**
|
||||
1. Create account at [railway.app](https://railway.app)
|
||||
2. Create new project
|
||||
3. Connect GitHub repository
|
||||
4. Configure environment variables
|
||||
5. Deploy
|
||||
|
||||
**Configuration:**
|
||||
- Start command: `npm start` or `node server.js`
|
||||
- Build command: `npm install`
|
||||
|
||||
### Heroku Deployment (Full-Stack)
|
||||
|
||||
**Steps:**
|
||||
1. Create account at [heroku.com](https://heroku.com)
|
||||
2. Install Heroku CLI
|
||||
3. Create Heroku app
|
||||
4. Configure environment variables
|
||||
5. Deploy
|
||||
|
||||
**Configuration:**
|
||||
- Procfile: `web: node server.js`
|
||||
- Environment variables in Heroku dashboard
|
||||
|
||||
### Render Deployment
|
||||
|
||||
**Steps:**
|
||||
1. Create account at [render.com](https://render.com)
|
||||
2. Create new service
|
||||
3. Connect GitHub repository
|
||||
4. Configure build and start commands
|
||||
5. Add environment variables
|
||||
6. Deploy
|
||||
|
||||
**Configuration:**
|
||||
- Build command: `npm install`
|
||||
- Start command: `npm start`
|
||||
|
||||
## Domain Configuration
|
||||
|
||||
### Setting Up Custom Domain
|
||||
|
||||
**General Steps:**
|
||||
1. Purchase domain from registrar
|
||||
2. Configure DNS records
|
||||
3. Add domain to hosting provider
|
||||
4. Update SSL certificate
|
||||
5. Verify domain ownership
|
||||
|
||||
**DNS Configuration:**
|
||||
- Add A record pointing to hosting IP
|
||||
- Add CNAME record for subdomains
|
||||
- Configure SSL/TLS certificates
|
||||
|
||||
## Deployment Checklist
|
||||
|
||||
- [ ] Application is tested and working locally
|
||||
- [ ] Environment variables are configured
|
||||
- [ ] Database is set up (if applicable)
|
||||
- [ ] Build process works correctly
|
||||
- [ ] Deployment platform is configured
|
||||
- [ ] Domain is configured (optional)
|
||||
- [ ] SSL certificate is active
|
||||
- [ ] Application is accessible and functional
|
||||
- [ ] Error monitoring is set up (optional)
|
||||
- [ ] Analytics are configured (optional)
|
||||
|
||||
---
|
||||
|
||||
*Proper documentation and deployment make your project professional and accessible. Take time to polish these aspects.*
|
||||
|
||||
@@ -0,0 +1,187 @@
|
||||
---
|
||||
title: Goal Setting Resources
|
||||
---
|
||||
|
||||
**ROADMAP TEMPLATES AND GOAL-SETTING RESOURCES**
|
||||
|
||||
## Roadmap Templates
|
||||
|
||||
### Front-End Developer Roadmap
|
||||
|
||||
**Weeks 1-4: Foundations**
|
||||
- HTML/CSS fundamentals
|
||||
- JavaScript basics
|
||||
- Responsive design principles
|
||||
- Version control (Git/GitHub)
|
||||
- Project: Build a responsive landing page
|
||||
|
||||
**Weeks 5-8: Frameworks & Libraries**
|
||||
- Learn a front-end framework (React, Vue, or Angular)
|
||||
- Component-based architecture
|
||||
- State management basics
|
||||
- Build tools (Webpack, Vite, etc.)
|
||||
- Project: Build a single-page application
|
||||
|
||||
**Weeks 9-12: Advanced Topics**
|
||||
- API integration
|
||||
- Testing (Jest, React Testing Library)
|
||||
- Performance optimization
|
||||
- Accessibility (WCAG guidelines)
|
||||
- Project: Build a full-featured front-end application
|
||||
|
||||
### Back-End Developer Roadmap
|
||||
|
||||
**Weeks 1-4: Foundations**
|
||||
- Choose a language (Node.js, Python, Java, etc.)
|
||||
- Database fundamentals (SQL)
|
||||
- RESTful API design
|
||||
- Version control (Git/GitHub)
|
||||
- Project: Build a simple API
|
||||
|
||||
**Weeks 5-8: Advanced Back-End**
|
||||
- Database design and optimization
|
||||
- Authentication and authorization
|
||||
- API security best practices
|
||||
- Error handling and logging
|
||||
- Project: Build a secure API with authentication
|
||||
|
||||
**Weeks 9-12: Production-Ready Skills**
|
||||
- Testing (unit, integration, e2e)
|
||||
- Deployment and DevOps basics
|
||||
- Caching strategies
|
||||
- Performance optimization
|
||||
- Project: Build a production-ready back-end system
|
||||
|
||||
### Full-Stack Developer Roadmap
|
||||
|
||||
**Weeks 1-4: Foundations**
|
||||
- Front-end basics (HTML, CSS, JavaScript)
|
||||
- Back-end basics (choose a stack)
|
||||
- Database fundamentals
|
||||
- Version control
|
||||
- Project: Build a simple full-stack application
|
||||
|
||||
**Weeks 5-8: Integration**
|
||||
- Connect front-end and back-end
|
||||
- API design and consumption
|
||||
- Authentication flow
|
||||
- State management
|
||||
- Project: Build an authenticated full-stack app
|
||||
|
||||
**Weeks 9-12: Advanced Full-Stack**
|
||||
- Testing across the stack
|
||||
- Deployment pipeline
|
||||
- Performance optimization
|
||||
- Security best practices
|
||||
- Project: Build a production-ready full-stack application
|
||||
|
||||
### Mobile Developer Roadmap
|
||||
|
||||
**Weeks 1-4: Foundations**
|
||||
- Choose platform (iOS/Swift, Android/Kotlin, or React Native/Flutter)
|
||||
- Platform-specific fundamentals
|
||||
- UI/UX principles for mobile
|
||||
- Version control
|
||||
- Project: Build a simple mobile app
|
||||
|
||||
**Weeks 5-8: Advanced Mobile**
|
||||
- Navigation and routing
|
||||
- State management
|
||||
- API integration
|
||||
- Platform-specific features
|
||||
- Project: Build a feature-rich mobile app
|
||||
|
||||
**Weeks 9-12: Production Skills**
|
||||
- Testing mobile applications
|
||||
- App store deployment
|
||||
- Performance optimization
|
||||
- Push notifications
|
||||
- Project: Build and deploy a mobile application
|
||||
|
||||
### Game Developer Roadmap
|
||||
|
||||
**Weeks 1-4: Foundations**
|
||||
- Choose game engine (Unity, Unreal, Godot, etc.)
|
||||
- Game design fundamentals
|
||||
- Basic scripting
|
||||
- Version control
|
||||
- Project: Build a simple game prototype
|
||||
|
||||
**Weeks 5-8: Game Development**
|
||||
- Game mechanics implementation
|
||||
- Asset integration
|
||||
- Physics and collision detection
|
||||
- User input handling
|
||||
- Project: Build a playable game
|
||||
|
||||
**Weeks 9-12: Polish & Deployment**
|
||||
- UI/UX for games
|
||||
- Sound and music integration
|
||||
- Performance optimization
|
||||
- Game deployment
|
||||
- Project: Polish and deploy a complete game
|
||||
|
||||
## Customizing Your Roadmap
|
||||
|
||||
### Self-Assessment Questions
|
||||
|
||||
1. **What is your current skill level?**
|
||||
- Complete beginner
|
||||
- Some experience with programming
|
||||
- Intermediate level
|
||||
- Advanced in some areas
|
||||
|
||||
2. **How much time can you commit per week?**
|
||||
- 5-10 hours
|
||||
- 10-20 hours
|
||||
- 20+ hours
|
||||
|
||||
3. **What are your learning preferences?**
|
||||
- Prefer structured learning
|
||||
- Prefer project-based learning
|
||||
- Mix of both
|
||||
|
||||
4. **What are your career goals?**
|
||||
- Specific role you're targeting
|
||||
- Industries you're interested in
|
||||
- Types of projects you want to work on
|
||||
|
||||
### Roadmap Customization Tips
|
||||
|
||||
- **Adjust timelines** based on your available time
|
||||
- **Add or remove topics** based on your goals
|
||||
- **Focus on areas** where you need the most improvement
|
||||
- **Include projects** that interest you
|
||||
- **Update regularly** as you learn and grow
|
||||
|
||||
## Roadmap Examples
|
||||
|
||||
### Example: Customized Front-End Roadmap
|
||||
|
||||
**Weeks 1-3: HTML/CSS Deep Dive**
|
||||
- Advanced CSS (Grid, Flexbox, animations)
|
||||
- CSS preprocessors (Sass)
|
||||
- Project: Build a complex landing page
|
||||
|
||||
**Weeks 4-6: JavaScript Mastery**
|
||||
- ES6+ features
|
||||
- Async programming
|
||||
- DOM manipulation
|
||||
- Project: Build an interactive web app
|
||||
|
||||
**Weeks 7-9: React Framework**
|
||||
- React fundamentals
|
||||
- Hooks and context
|
||||
- Routing
|
||||
- Project: Build a React application
|
||||
|
||||
**Weeks 10-12: Production Skills**
|
||||
- Testing
|
||||
- Performance optimization
|
||||
- Deployment
|
||||
- Project: Polish and deploy React app
|
||||
|
||||
---
|
||||
|
||||
*These templates are starting points. Customize them to fit your individual needs, timeline, and goals.*
|
||||
|
||||
@@ -0,0 +1,212 @@
|
||||
---
|
||||
title: Priority and Effort Resources
|
||||
---
|
||||
|
||||
**PRIORITY ASSIGNMENT AND EFFORT ESTIMATION GUIDES**
|
||||
|
||||
## Priority Assignment Guide
|
||||
|
||||
### Understanding Priority
|
||||
|
||||
**Priority is based on dependencies, not personal preference.**
|
||||
|
||||
Priority determines the order in which user stories should be completed based on:
|
||||
- Which stories block other stories
|
||||
- Which stories must be completed first
|
||||
- Logical sequence requirements
|
||||
|
||||
### Priority Assignment Process
|
||||
|
||||
#### Step 1: Identify Dependencies
|
||||
|
||||
**Questions to Ask:**
|
||||
- Which stories must be completed before others can start?
|
||||
- Which stories block multiple other stories?
|
||||
- What is the logical sequence of feature development?
|
||||
|
||||
**Example:**
|
||||
- Authentication must be completed before user-specific features
|
||||
- Database models must exist before features that use them
|
||||
- Core features must exist before advanced features
|
||||
|
||||
#### Step 2: Map Dependencies
|
||||
|
||||
**Create a dependency map:**
|
||||
- List all user stories
|
||||
- Identify which stories depend on others
|
||||
- Identify which stories block others
|
||||
- Create a dependency graph
|
||||
|
||||
#### Step 3: Assign Priority Levels
|
||||
|
||||
**Priority Levels:**
|
||||
- **High Priority:** Blocks multiple other stories or is foundational
|
||||
- **Medium Priority:** Blocked by high priority, may block some stories
|
||||
- **Low Priority:** Blocked by other stories, doesn't block others
|
||||
|
||||
### Priority Example
|
||||
|
||||
**User Stories:**
|
||||
1. As an unauthenticated user, I can create an account
|
||||
2. As an authenticated user, I can view my profile
|
||||
3. As an authenticated user, I can edit my profile
|
||||
4. As an authenticated user, I can create a post
|
||||
5. As a user, I can view posts from other users
|
||||
|
||||
**Dependency Analysis:**
|
||||
- Story 1 blocks stories 2, 3, and 4 (authentication required)
|
||||
- Story 2 blocks story 3 (must view before editing)
|
||||
- Story 4 blocks story 5 (must create before viewing)
|
||||
- Stories 2 and 4 don't block each other
|
||||
|
||||
**Priority Assignment:**
|
||||
- **High:** Story 1 (blocks multiple stories)
|
||||
- **Medium:** Stories 2 and 4 (blocked by 1, but don't block each other)
|
||||
- **Low:** Stories 3 and 5 (blocked by other stories)
|
||||
|
||||
## Effort Estimation Guide
|
||||
|
||||
### Understanding Effort
|
||||
|
||||
**Effort represents the amount of work required to complete a story.**
|
||||
|
||||
Effort helps you:
|
||||
- Plan your work timeline
|
||||
- Balance high-priority tasks with available time
|
||||
- Estimate project completion
|
||||
- Make informed decisions about task selection
|
||||
|
||||
### Effort Estimation Methods
|
||||
|
||||
#### Story Points
|
||||
|
||||
**Common Scales:**
|
||||
- **Fibonacci:** 1, 2, 3, 5, 8, 13, 21
|
||||
- **T-Shirt Sizes:** XS, S, M, L, XL
|
||||
- **Linear:** 1, 2, 3, 4, 5
|
||||
|
||||
**Story Point Guidelines:**
|
||||
- **1-2 points:** Simple, straightforward tasks
|
||||
- **3-5 points:** Moderate complexity, some unknowns
|
||||
- **8-13 points:** Complex, multiple components, significant unknowns
|
||||
- **21+ points:** Very complex, should be broken down
|
||||
|
||||
#### Time-Based Estimation
|
||||
|
||||
**Time Estimates:**
|
||||
- **Small:** 1-4 hours
|
||||
- **Medium:** 4-16 hours
|
||||
- **Large:** 16-40 hours
|
||||
- **Very Large:** 40+ hours (consider breaking down)
|
||||
|
||||
### Effort Estimation Factors
|
||||
|
||||
**Consider:**
|
||||
- **Complexity:** How complex is the implementation?
|
||||
- **Uncertainty:** How much is unknown?
|
||||
- **Dependencies:** Are dependencies clear and available?
|
||||
- **Scope:** How much work is involved?
|
||||
- **Risk:** What could go wrong?
|
||||
|
||||
### Effort Example
|
||||
|
||||
**User Stories with Effort Estimates:**
|
||||
|
||||
1. **Create account (5 points):** Building entire authentication flow is complex
|
||||
2. **View profile (3 points):** Moderate complexity, needs API and UI
|
||||
3. **Edit profile (3 points):** Similar to view, plus update logic
|
||||
4. **Create post (5 points):** Complex with validation, API, UI
|
||||
5. **View posts (1 point):** Simple display of existing data
|
||||
|
||||
## Label Examples
|
||||
|
||||
### Priority Labels
|
||||
|
||||
**Option 1: Text Labels**
|
||||
- `priority: high`
|
||||
- `priority: medium`
|
||||
- `priority: low`
|
||||
|
||||
**Option 2: Numbered**
|
||||
- `priority: 1` (highest)
|
||||
- `priority: 2`
|
||||
- `priority: 3` (lowest)
|
||||
|
||||
**Option 3: Descriptive**
|
||||
- `priority: critical`
|
||||
- `priority: important`
|
||||
- `priority: nice-to-have`
|
||||
|
||||
### Effort Labels
|
||||
|
||||
**Option 1: Story Points**
|
||||
- `effort: 1`
|
||||
- `effort: 2`
|
||||
- `effort: 3`
|
||||
- `effort: 5`
|
||||
- `effort: 8`
|
||||
- `effort: 13`
|
||||
|
||||
**Option 2: T-Shirt Sizes**
|
||||
- `effort: xs`
|
||||
- `effort: s`
|
||||
- `effort: m`
|
||||
- `effort: l`
|
||||
- `effort: xl`
|
||||
|
||||
**Option 3: Time-Based**
|
||||
- `effort: small` (1-4 hours)
|
||||
- `effort: medium` (4-16 hours)
|
||||
- `effort: large` (16-40 hours)
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Priority Best Practices
|
||||
|
||||
✅ Base priority on dependencies, not interest
|
||||
✅ Review dependencies carefully
|
||||
✅ Update priorities as dependencies change
|
||||
✅ Consider blocking relationships
|
||||
|
||||
❌ Don't prioritize based on what's most fun
|
||||
❌ Don't prioritize based on excitement level
|
||||
❌ Don't ignore dependencies
|
||||
|
||||
### Effort Best Practices
|
||||
|
||||
✅ Be honest about complexity
|
||||
✅ Consider unknowns and risks
|
||||
✅ Break down large stories
|
||||
✅ Review estimates after completion to improve
|
||||
|
||||
❌ Don't underestimate complex tasks
|
||||
❌ Don't overestimate simple tasks
|
||||
❌ Don't ignore your own skill level
|
||||
|
||||
## Combining Priority and Effort
|
||||
|
||||
### Work Planning Strategy
|
||||
|
||||
**When you have limited time:**
|
||||
- Choose high-priority, low-effort tasks first
|
||||
- This allows progress even with time constraints
|
||||
|
||||
**When you have more time:**
|
||||
- Tackle high-priority, high-effort tasks
|
||||
- These are often foundational and important
|
||||
|
||||
**Example Decision Matrix:**
|
||||
|
||||
| Priority | Effort | Action |
|
||||
|----------|--------|--------|
|
||||
| High | Low | Do first |
|
||||
| High | High | Do when you have time |
|
||||
| Medium | Low | Good for quick wins |
|
||||
| Medium | High | Plan for dedicated time |
|
||||
| Low | Low | Do when caught up |
|
||||
| Low | High | Consider breaking down |
|
||||
|
||||
---
|
||||
|
||||
*Priority and effort help you plan and execute work effectively. Use them together to make informed decisions about what to work on.*
|
||||
|
||||
@@ -0,0 +1,200 @@
|
||||
---
|
||||
title: Project Planning Resources
|
||||
---
|
||||
|
||||
**PROJECT PLAN EXAMPLES AND BRAINSTORMING GUIDES**
|
||||
|
||||
## Project Plan Example
|
||||
|
||||
### Example: Task Management Application
|
||||
|
||||
**Project Overview:**
|
||||
A full-stack task management application that allows users to create, organize, and track tasks with features like kanban boards, task dependencies, and project rewards.
|
||||
|
||||
**Core Features:**
|
||||
1. User authentication and authorization
|
||||
2. Task creation and management
|
||||
3. Kanban board view
|
||||
4. Task dependencies
|
||||
5. Project organization
|
||||
6. Reward system for completed projects
|
||||
7. Gamification elements (optional)
|
||||
|
||||
**Technical Stack:**
|
||||
- Front-end: React with TypeScript
|
||||
- Back-end: Node.js with Express
|
||||
- Database: PostgreSQL
|
||||
- Authentication: JWT
|
||||
- Deployment: Vercel (front-end), Railway (back-end)
|
||||
|
||||
**Project Structure:**
|
||||
- User authentication system
|
||||
- Task CRUD operations
|
||||
- Project management
|
||||
- Kanban board interface
|
||||
- Dependency tracking
|
||||
- Reward system
|
||||
- Gamification features
|
||||
|
||||
**Timeline:**
|
||||
- Weeks 1-2: Setup and authentication
|
||||
- Weeks 3-4: Core task functionality
|
||||
- Weeks 5-6: Kanban board and views
|
||||
- Weeks 7-8: Dependencies and projects
|
||||
- Weeks 9-10: Reward system
|
||||
- Weeks 11-12: Gamification and polish
|
||||
|
||||
## Project Idea Brainstorming Guide
|
||||
|
||||
### Step 1: Identify Your Interests
|
||||
|
||||
**Questions to Ask:**
|
||||
- What problems do you encounter in your daily life?
|
||||
- What tools or applications do you wish existed?
|
||||
- What hobbies or interests do you have?
|
||||
- What industries are you curious about?
|
||||
|
||||
**Examples:**
|
||||
- Daily life: Meal planning, expense tracking, habit tracking
|
||||
- Tools: Code snippet manager, design asset organizer
|
||||
- Hobbies: Music playlist creator, workout tracker, recipe manager
|
||||
- Industries: Healthcare apps, education tools, productivity software
|
||||
|
||||
### Step 2: Define the Problem
|
||||
|
||||
**Problem Statement Template:**
|
||||
"As a [user type], I need [what they need] because [why they need it]."
|
||||
|
||||
**Example:**
|
||||
"As a developer, I need a way to organize and quickly access my code snippets because I waste time searching through notes and documentation."
|
||||
|
||||
### Step 3: Identify Core Features
|
||||
|
||||
**Feature Brainstorming:**
|
||||
- What are the essential features (MVP)?
|
||||
- What features would be nice to have?
|
||||
- What features are stretch goals?
|
||||
|
||||
**MVP Features:**
|
||||
- Core functionality that solves the main problem
|
||||
- User authentication (if needed)
|
||||
- Basic CRUD operations
|
||||
- Essential UI/UX
|
||||
|
||||
**Nice-to-Have Features:**
|
||||
- Advanced functionality
|
||||
- Additional views or interfaces
|
||||
- Integration with other services
|
||||
- Advanced customization
|
||||
|
||||
**Stretch Goals:**
|
||||
- Gamification
|
||||
- Social features
|
||||
- Advanced analytics
|
||||
- Mobile apps
|
||||
|
||||
### Step 4: Choose Your Tech Stack
|
||||
|
||||
**Considerations:**
|
||||
- What technologies align with your career goals?
|
||||
- What technologies are you learning?
|
||||
- What technologies are in demand for your target roles?
|
||||
- What technologies interest you?
|
||||
|
||||
**Common Stacks:**
|
||||
- **MERN:** MongoDB, Express, React, Node.js
|
||||
- **PERN:** PostgreSQL, Express, React, Node.js
|
||||
- **MEVN:** MongoDB, Express, Vue, Node.js
|
||||
- **Django/Flask + React:** Python back-end, React front-end
|
||||
- **Ruby on Rails + React:** Ruby back-end, React front-end
|
||||
|
||||
### Step 5: Plan Your Project Structure
|
||||
|
||||
**Project Components:**
|
||||
- Authentication system
|
||||
- Core feature modules
|
||||
- Database schema
|
||||
- API endpoints
|
||||
- Front-end components
|
||||
- Testing strategy
|
||||
- Deployment plan
|
||||
|
||||
## Project Planning Template
|
||||
|
||||
```markdown
|
||||
# [Project Name]
|
||||
|
||||
## Project Overview
|
||||
[Brief description of what the project does and why it exists]
|
||||
|
||||
## Problem Statement
|
||||
[What problem does this solve? Who is it for?]
|
||||
|
||||
## Core Features (MVP)
|
||||
1. [Feature 1]
|
||||
2. [Feature 2]
|
||||
3. [Feature 3]
|
||||
|
||||
## Nice-to-Have Features
|
||||
1. [Feature 1]
|
||||
2. [Feature 2]
|
||||
|
||||
## Stretch Goals
|
||||
1. [Feature 1]
|
||||
2. [Feature 2]
|
||||
|
||||
## Technical Stack
|
||||
- Front-end: [Technology]
|
||||
- Back-end: [Technology]
|
||||
- Database: [Technology]
|
||||
- Other: [Technologies]
|
||||
|
||||
## Project Structure
|
||||
- [Component/Module 1]
|
||||
- [Component/Module 2]
|
||||
- [Component/Module 3]
|
||||
|
||||
## Timeline
|
||||
- Week 1-2: [Milestone]
|
||||
- Week 3-4: [Milestone]
|
||||
- Week 5-6: [Milestone]
|
||||
- Week 7-8: [Milestone]
|
||||
- Week 9-10: [Milestone]
|
||||
- Week 11-12: [Milestone]
|
||||
|
||||
## Success Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- [ ] [Criterion 3]
|
||||
```
|
||||
|
||||
## Additional Project Ideas
|
||||
|
||||
### Beginner-Friendly Projects
|
||||
- Todo list application
|
||||
- Weather app
|
||||
- Calculator
|
||||
- Quiz application
|
||||
- Blog platform
|
||||
- Recipe finder
|
||||
|
||||
### Intermediate Projects
|
||||
- E-commerce site
|
||||
- Social media platform
|
||||
- Project management tool
|
||||
- Chat application
|
||||
- Expense tracker
|
||||
- Learning management system
|
||||
|
||||
### Advanced Projects
|
||||
- Real-time collaboration tool
|
||||
- Video streaming platform
|
||||
- Marketplace application
|
||||
- Analytics dashboard
|
||||
- AI-powered application
|
||||
- Blockchain-based application
|
||||
|
||||
---
|
||||
|
||||
*Use these examples and templates as starting points. The best projects solve real problems and demonstrate your skills effectively.*
|
||||
|
||||
@@ -0,0 +1,246 @@
|
||||
---
|
||||
title: Technical Breakdown Resources
|
||||
---
|
||||
|
||||
**TECHNICAL BREAKDOWN TEMPLATE AND EXAMPLES**
|
||||
|
||||
## Technical Breakdown Template
|
||||
|
||||
Copy this template into each user story issue:
|
||||
|
||||
```markdown
|
||||
## 🎯 Acceptance Criteria
|
||||
- [ ] Criteria 1 (clear, testable condition)
|
||||
- [ ] Criteria 2
|
||||
- [ ] Criteria 3
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Technical Details
|
||||
- Proposed implementation approach:
|
||||
- [ ] e.g., API endpoint, UI component, database schema changes
|
||||
- Data considerations:
|
||||
- [ ] Models, validation, storage needs
|
||||
- Security/permissions:
|
||||
- [ ] Any auth or role checks?
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Dependencies
|
||||
- [ ] Related tickets or features
|
||||
- [ ] External services or APIs
|
||||
- [ ] Libraries or frameworks required
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Testing Notes
|
||||
- [ ] Unit tests to cover…
|
||||
- [ ] Integration tests to cover…
|
||||
- [ ] Manual QA steps…
|
||||
|
||||
---
|
||||
|
||||
## 📂 Additional Context
|
||||
- Links to designs, diagrams, or docs
|
||||
- Any constraints or assumptions
|
||||
- Open questions / things to clarify
|
||||
```
|
||||
|
||||
## Technical Breakdown Example
|
||||
|
||||
### Example User Story
|
||||
|
||||
**User Story:** As an authenticated user, I should be able to add a game to my library.
|
||||
|
||||
### Completed Technical Breakdown
|
||||
|
||||
```markdown
|
||||
## 🎯 Acceptance Criteria
|
||||
- [ ] User can add game to library via API endpoint
|
||||
- [ ] User can view games in their library
|
||||
- [ ] User can remove game from library
|
||||
- [ ] User cannot add duplicate games to library
|
||||
- [ ] Only authenticated users can modify their library
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Technical Details
|
||||
- Proposed implementation approach:
|
||||
- [ ] POST /api/library endpoint to add game
|
||||
- [ ] GET /api/library endpoint to retrieve user's library
|
||||
- [ ] DELETE /api/library/:gameId endpoint to remove game
|
||||
- [ ] Front-end component to display library
|
||||
- [ ] Front-end component with add/remove buttons
|
||||
- Data considerations:
|
||||
- [ ] User model must have library property (array of game IDs)
|
||||
- [ ] Each game ID references a Game model record
|
||||
- [ ] Validate game ID exists before adding
|
||||
- [ ] Prevent duplicate entries in library array
|
||||
- [ ] Consider pagination for large libraries
|
||||
- Security/permissions:
|
||||
- [ ] Validate JWT token on all endpoints
|
||||
- [ ] Ensure authenticated user can only modify their own library
|
||||
- [ ] Validate game ID to prevent invalid references
|
||||
- [ ] Rate limiting to prevent abuse
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Dependencies
|
||||
- [ ] #2 - User authentication must be implemented first
|
||||
- [ ] #5 - Game model must exist
|
||||
- [ ] #8 - Profile UI necessary to access library view
|
||||
- [ ] JWT authentication library
|
||||
- [ ] Express middleware for JWT validation
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Testing Notes
|
||||
- [ ] Unit tests:
|
||||
- [ ] POST endpoint adds game to library
|
||||
- [ ] POST endpoint prevents duplicates
|
||||
- [ ] GET endpoint returns user's library
|
||||
- [ ] DELETE endpoint removes game from library
|
||||
- [ ] Endpoints reject unauthenticated requests
|
||||
- [ ] Endpoints prevent users from modifying other users' libraries
|
||||
- [ ] Integration tests:
|
||||
- [ ] Full flow: add game, view library, remove game
|
||||
- [ ] Authentication flow with library operations
|
||||
- [ ] Manual QA steps:
|
||||
- [ ] Test adding game via UI
|
||||
- [ ] Test viewing library
|
||||
- [ ] Test removing game
|
||||
- [ ] Test error handling (invalid game ID, duplicate, etc.)
|
||||
- [ ] Test with multiple users to ensure isolation
|
||||
|
||||
---
|
||||
|
||||
## 📂 Additional Context
|
||||
- Relational data model means using MongoDB might not be the best choice. Should we re-evaluate database choice?
|
||||
- Consider adding a GET /api/library/:userId endpoint for viewing other users' libraries (future feature)
|
||||
- May want to add library statistics (total games, recently added, etc.)
|
||||
- Consider caching library data for performance
|
||||
```
|
||||
|
||||
## Technical Breakdown Guide
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
**Purpose:** Define clear, testable conditions for story completion.
|
||||
|
||||
**Tips:**
|
||||
- Make criteria specific and measurable
|
||||
- Focus on behavior, not implementation
|
||||
- Ensure criteria are testable
|
||||
- Cover both happy path and edge cases
|
||||
|
||||
**Examples:**
|
||||
- ✅ "User can add game to library"
|
||||
- ✅ "User cannot add duplicate games"
|
||||
- ❌ "Implement library feature" (too vague)
|
||||
- ❌ "Use MongoDB" (implementation detail)
|
||||
|
||||
### Technical Details
|
||||
|
||||
**Implementation Approach:**
|
||||
- What components/modules will be created?
|
||||
- What API endpoints are needed?
|
||||
- What UI components are required?
|
||||
- What database changes are needed?
|
||||
|
||||
**Data Considerations:**
|
||||
- What data models are involved?
|
||||
- What validation is needed?
|
||||
- What relationships exist?
|
||||
- What storage requirements are there?
|
||||
|
||||
**Security/Permissions:**
|
||||
- What authentication is required?
|
||||
- What authorization checks are needed?
|
||||
- What data should be protected?
|
||||
- What rate limiting is appropriate?
|
||||
|
||||
### Dependencies
|
||||
|
||||
**Types of Dependencies:**
|
||||
- **Feature Dependencies:** Other user stories that must be completed first
|
||||
- **Technical Dependencies:** Libraries, frameworks, or services needed
|
||||
- **External Dependencies:** Third-party APIs or services
|
||||
|
||||
**Identifying Dependencies:**
|
||||
- What must exist before this can be built?
|
||||
- What external services are needed?
|
||||
- What libraries or frameworks are required?
|
||||
- What infrastructure is needed?
|
||||
|
||||
### Testing Notes
|
||||
|
||||
**Unit Tests:**
|
||||
- Test individual functions/methods
|
||||
- Test edge cases and error handling
|
||||
- Test validation logic
|
||||
- Test business rules
|
||||
|
||||
**Integration Tests:**
|
||||
- Test component interactions
|
||||
- Test API endpoints
|
||||
- Test database operations
|
||||
- Test authentication/authorization flows
|
||||
|
||||
**Manual QA:**
|
||||
- Test user workflows
|
||||
- Test UI interactions
|
||||
- Test error scenarios
|
||||
- Test across different browsers/devices
|
||||
|
||||
### Additional Context
|
||||
|
||||
**Include:**
|
||||
- Design mockups or wireframes
|
||||
- Architecture diagrams
|
||||
- Related documentation
|
||||
- Constraints or limitations
|
||||
- Open questions or concerns
|
||||
- Future considerations
|
||||
|
||||
## Common Technical Patterns
|
||||
|
||||
### API Endpoint Pattern
|
||||
|
||||
```markdown
|
||||
## ⚙️ Technical Details
|
||||
- Proposed implementation approach:
|
||||
- [ ] POST /api/resource endpoint
|
||||
- [ ] Request validation middleware
|
||||
- [ ] Database operation
|
||||
- [ ] Response formatting
|
||||
- Data considerations:
|
||||
- [ ] Resource model schema
|
||||
- [ ] Required fields validation
|
||||
- [ ] Data relationships
|
||||
- Security/permissions:
|
||||
- [ ] JWT authentication required
|
||||
- [ ] Role-based authorization
|
||||
```
|
||||
|
||||
### UI Component Pattern
|
||||
|
||||
```markdown
|
||||
## ⚙️ Technical Details
|
||||
- Proposed implementation approach:
|
||||
- [ ] Component structure (e.g., React component)
|
||||
- [ ] State management
|
||||
- [ ] API integration
|
||||
- [ ] Error handling UI
|
||||
- Data considerations:
|
||||
- [ ] Component props/state
|
||||
- [ ] Data fetching strategy
|
||||
- [ ] Loading states
|
||||
- Security/permissions:
|
||||
- [ ] Conditional rendering based on user role
|
||||
- [ ] Protected routes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*Technical breakdowns help you plan implementation before coding. Take time to think through all aspects of the feature.*
|
||||
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
title: User Story Resources
|
||||
---
|
||||
|
||||
**USER STORY TEMPLATES, EXAMPLES, AND WRITING GUIDES**
|
||||
|
||||
## User Story Format
|
||||
|
||||
### Standard Format
|
||||
|
||||
```
|
||||
As a [user type], I want [goal/desire] so that [benefit/value].
|
||||
```
|
||||
|
||||
### Components
|
||||
|
||||
- **User Type:** Who is the user? (e.g., authenticated user, admin, guest)
|
||||
- **Goal/Desire:** What do they want to do?
|
||||
- **Benefit/Value:** Why do they want this? What value does it provide?
|
||||
|
||||
## User Story Examples
|
||||
|
||||
### Authentication Examples
|
||||
|
||||
**Example 1:**
|
||||
As an unauthenticated user, I can create an account so that I can access personalized features.
|
||||
|
||||
**Example 2:**
|
||||
As an unauthenticated user, I can sign in to my existing account so that I can access my saved data.
|
||||
|
||||
**Example 3:**
|
||||
As an authenticated user, I can sign out so that I can secure my account when using shared devices.
|
||||
|
||||
### Profile Management Examples
|
||||
|
||||
**Example 1:**
|
||||
As an authenticated user, I can view my profile so that I can see my account information.
|
||||
|
||||
**Example 2:**
|
||||
As an authenticated user, I can edit my profile information so that I can keep my details up to date.
|
||||
|
||||
**Example 3:**
|
||||
As an authenticated user, I can upload a profile picture so that others can identify me.
|
||||
|
||||
### Content Management Examples
|
||||
|
||||
**Example 1:**
|
||||
As an authenticated user, I can create a new post so that I can share content with others.
|
||||
|
||||
**Example 2:**
|
||||
As an authenticated user, I can edit my own posts so that I can correct mistakes or update information.
|
||||
|
||||
**Example 3:**
|
||||
As an authenticated user, I can delete my own posts so that I can remove content I no longer want to share.
|
||||
|
||||
**Example 4:**
|
||||
As a user, I can view posts from other users so that I can see community content.
|
||||
|
||||
### Admin Examples
|
||||
|
||||
**Example 1:**
|
||||
As an administrator, I can review posts for content violations so that I can maintain community standards.
|
||||
|
||||
**Example 2:**
|
||||
As an administrator, I can remove posts that violate policies so that I can keep the community safe.
|
||||
|
||||
**Example 3:**
|
||||
As an administrator, I can view user analytics so that I can understand community engagement.
|
||||
|
||||
### Task Management Examples
|
||||
|
||||
**Example 1:**
|
||||
As an authenticated user, I can create a new task so that I can track work that needs to be done.
|
||||
|
||||
**Example 2:**
|
||||
As an authenticated user, I can mark a task as complete so that I can track my progress.
|
||||
|
||||
**Example 3:**
|
||||
As an authenticated user, I can organize tasks into projects so that I can group related work.
|
||||
|
||||
**Example 4:**
|
||||
As an authenticated user, I can set task dependencies so that I can ensure tasks are completed in the correct order.
|
||||
|
||||
## User Story Writing Guide
|
||||
|
||||
### Step 1: Identify User Types
|
||||
|
||||
**Common User Types:**
|
||||
- Unauthenticated user (guest, visitor)
|
||||
- Authenticated user (logged-in user)
|
||||
- Administrator (admin, moderator)
|
||||
- Premium user (if applicable)
|
||||
- Specific roles (e.g., teacher, student, manager)
|
||||
|
||||
### Step 2: Think About User Goals
|
||||
|
||||
**Questions to Ask:**
|
||||
- What does this user type want to accomplish?
|
||||
- What actions do they need to take?
|
||||
- What information do they need to see?
|
||||
- What features would be valuable to them?
|
||||
|
||||
### Step 3: Consider the Value
|
||||
|
||||
**Value Considerations:**
|
||||
- Why is this feature important?
|
||||
- What problem does it solve?
|
||||
- How does it improve the user experience?
|
||||
- What benefit does it provide?
|
||||
|
||||
### Step 4: Write the Story
|
||||
|
||||
**Writing Tips:**
|
||||
- Keep it simple and focused
|
||||
- One feature per story
|
||||
- Use clear, concise language
|
||||
- Focus on user value, not implementation
|
||||
|
||||
### Step 5: Review and Refine
|
||||
|
||||
**Review Checklist:**
|
||||
- Is the user type clear?
|
||||
- Is the goal specific and actionable?
|
||||
- Is the value/benefit clear?
|
||||
- Is it testable?
|
||||
- Is it independent (can be developed separately)?
|
||||
|
||||
## User Story Template
|
||||
|
||||
```markdown
|
||||
## User Story: [Brief Title]
|
||||
|
||||
**As a** [user type]
|
||||
**I want** [goal/desire]
|
||||
**So that** [benefit/value]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- [ ] [Criterion 3]
|
||||
|
||||
### Notes
|
||||
[Any additional context or considerations]
|
||||
```
|
||||
|
||||
## Common User Story Patterns
|
||||
|
||||
### CRUD Operations
|
||||
|
||||
**Create:**
|
||||
As an authenticated user, I can create [resource] so that [value].
|
||||
|
||||
**Read/View:**
|
||||
As a user, I can view [resource] so that [value].
|
||||
|
||||
**Update:**
|
||||
As an authenticated user, I can edit [resource] so that [value].
|
||||
|
||||
**Delete:**
|
||||
As an authenticated user, I can delete [resource] so that [value].
|
||||
|
||||
### Authentication Flow
|
||||
|
||||
- Account creation
|
||||
- Sign in
|
||||
- Sign out
|
||||
- Password reset
|
||||
- Email verification
|
||||
- Profile management
|
||||
|
||||
### Content Management
|
||||
|
||||
- Create content
|
||||
- View content
|
||||
- Edit content
|
||||
- Delete content
|
||||
- Search/filter content
|
||||
- Organize content
|
||||
|
||||
### Social Features
|
||||
|
||||
- Follow users
|
||||
- Like/favourite content
|
||||
- Comment on content
|
||||
- Share content
|
||||
- Message users
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Do's
|
||||
|
||||
✅ Write from the user's perspective
|
||||
✅ Focus on value and benefits
|
||||
✅ Keep stories independent
|
||||
✅ Make stories testable
|
||||
✅ Use clear, simple language
|
||||
|
||||
### Don'ts
|
||||
|
||||
❌ Include technical implementation details
|
||||
❌ Combine multiple features
|
||||
❌ Use vague or ambiguous language
|
||||
❌ Focus on "how" instead of "what"
|
||||
❌ Make stories too large or complex
|
||||
|
||||
---
|
||||
|
||||
*User stories should be clear, focused, and user-centered. They guide development by keeping the focus on user value.*
|
||||
|
||||
Reference in New Issue
Block a user