0% found this document useful (0 votes)
15 views4 pages

Rules and Regulations for Documentation

The document outlines the rules and regulations for project documentation, hosting, and submission for a hackathon/webathon. It specifies requirements for a README.md file, including project details, technology stack, installation instructions, and testing processes, as well as guidelines for hosting and deploying projects. Additionally, it details GitHub repository rules, submission guidelines, judging criteria, and post-event transparency measures.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views4 pages

Rules and Regulations for Documentation

The document outlines the rules and regulations for project documentation, hosting, and submission for a hackathon/webathon. It specifies requirements for a README.md file, including project details, technology stack, installation instructions, and testing processes, as well as guidelines for hosting and deploying projects. Additionally, it details GitHub repository rules, submission guidelines, judging criteria, and post-event transparency measures.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Rules and Regulations for Documentation

1. Documentation Requirements

Every project must have a detailed and structured documentation file named README.md in
the root of the repository. This file should contain the following sections:

a. Project Overview

 Title of the project.


 Problem statement addressed.
 Objective and goals of the project.
 Key features and functionalities of the solution.
 Target audience or use case (e.g., students preparing for interviews, job seekers, etc.).

b. Technology Stack

 Clearly list all the technologies and tools used in the project (e.g., React.js, Node.js,
MongoDB, Puppeteer, etc.).
 Mention versions of major tools (e.g., React 18, Node.js 16).

c. System Requirements

 Hardware requirements (e.g., minimum system configurations to run the project


locally).
 Software requirements (e.g., specific software or frameworks that need to be
installed).

d. Installation and Setup Instructions

 Step-by-step guide to set up the project locally, including:


1. Cloning the repository.
2. Installing dependencies (npm install, pip install, etc.).
3. Database configuration and initialization (if applicable).
4. Running the application (e.g., npm start, python manage.py runserver).
 Include screenshots for clarity, especially for any complex steps.

e. Features Explanation

 Provide a detailed explanation of all features and how they work.


 Include GIFs, screenshots, or videos showcasing functionality like job searching,
resume building, or other core features.

f. Usage Instructions

 Explain how users (both job seekers and employers, in this case) can use the platform.
 Include a demo walkthrough:
o How a job seeker creates a resume, searches for jobs, and applies.
o How an employer posts job openings and reviews applications.
 Provide a link to the live project.

g. Code Structure

 Explain the project directory structure. For example:


 ├── src
 │ ├── components # Reusable components
 │ ├── pages # Pages like Home, Job Search, Resume
Builder
 │ ├── assets # Static assets like images and CSS
 │ └── utils # Utility functions
 ├── backend # Node.js backend API
 ├── database # Database-related scripts
 ├── README.md # Project documentation
 ├── package.json # Project dependencies
 Mention key files for functionalities like ResumeBuilder.js or JobSearchAPI.js.

h. Testing

 Describe the testing process for the application.


 List tools used for testing (e.g., Jest, Postman).
 Share test case examples or test coverage reports.

i. Challenges and Solutions

 Highlight the challenges faced during development.


 Explain how these challenges were addressed.

j. Future Enhancements

 Propose features or improvements that can be added in future iterations.

k. Credits and References

 Acknowledge team members, mentors, and any third-party tools or libraries used.

l. License

 Specify the license under which the code is shared (e.g., MIT License).

2. Hosting and Deployment

To make the project accessible, it must be hosted live on a suitable platform. Below are the
rules for deployment:

a. Hosting Platforms

 Use GitHub Pages for static frontend applications.


 Use Render, Netlify, or Vercel for full-stack applications.
 Ensure backend services (if applicable) are hosted and accessible via public endpoints
(e.g., Render, Railway, or AWS).

b. Deployment Steps

 Include clear instructions in the documentation on how to deploy the project on the
chosen platform.
 Share the live project URL prominently in the README.md.

c. Demo Video

 Create a short demo video (2–5 minutes) showcasing the live project and its key
functionalities.
 Upload the video to YouTube and include the link in the documentation.

3. Code Repository and GitHub Rules

Every project must follow these GitHub-related rules:

a. Repository Setup

 Push all code to a GitHub repository.


 The repository name should follow the format:
<team_name>_<problem_statement_title>
Example: TeamAlpha_ResumeBuilderJobPortal.
 Add a detailed description and tags to the repository.

b. Branching and Version Control

 Use branches for development:


o main: Stable, production-ready code.
o dev: Features under development.
o Additional branches for each feature/module (e.g., feature/resume-
builder).
 Use proper commit messages:
o Bad: Update code
o Good: Add job search filters based on location and skills

c. README.md

 Ensure the README.md is complete and well-formatted.


 Use markdown styling (e.g., headers, bullet points, code blocks).

d. GitHub Workflow

 Follow proper pull request and code review processes if working in a team.
 Use GitHub Issues for tracking bugs and feature requests.
e. Public Access

 Make the repository public before the submission deadline.

4. Submission Guidelines

 Submit the following:


1. GitHub Repository Link: Ensure it contains all code, documentation, and
resources.
2. Live Project Link: The hosted version of the project.
3. Demo Video Link: A video walkthrough of the project.
4. Team Details: Names, email IDs, and roles of all team members.
 Use the provided submission form or platform to upload these details.

5. General Rules

 Originality: Ensure the project is original and built during the hackathon/webathon
duration.
 Time Management: Complete the project within the allocated timeframe.
 Team Collaboration: Work collaboratively, ensuring all members contribute.
 No Plagiarism: Any instance of plagiarism will lead to disqualification.

6. Judging Criteria

Projects will be evaluated based on:

 Completeness: How well the solution addresses the problem statement.


 Functionality: Smooth and bug-free implementation of features.
 Creativity: Innovation in the approach or solution.
 Documentation: Clarity, detail, and presentation of the documentation.
 Deployment: Accessibility of the live project.

7. Post-Event

 All projects will remain accessible on GitHub for transparency.


 The top projects may be featured on the event’s official page or social media.

You might also like