Team Size

Each team can have a minimum of 2 and a maximum of 4 members. This structure shall ensure sufficient collaboration while maintaining manageable group dynamics.

 

Member Eligibility and Team Formation

All participants (as part of their respective teams) must be officially registered Unstop (registration platform) for the hackathon. It shall be ensured that no participant can hold privileged roles, such as that of organisers, judges, or mentors, to maintain absolute fairness. All teams (and members) shall be formed (and registered) prior to the hackathon and no changes can be accepted post the submission of the Hackathon Participation Acceptance Form, requiring the submission of their Student ID and Government-issued Identification Card.

 

Team Roles

To maximise efficiency, teams are advised to define specific roles for their members. Common roles include a developer who focuses on coding, a designer responsible for UI/UX or visuals, a project manager ensuring timelines and deliverables are met, and a domain expert offering specialised knowledge relevant to the project’s focus area.

---

 

./Project Development and Guidelines

 

Tools and Resources

  • Projects involving physical hardware or external devices are not permitted.
  • Teams can freely choose tools, IDEs, and programming languages that suit their project requirements. Game engines like Unity, Unreal Engine etc. are permitted, as well as AI tools for code generation or testing, provided their usage is disclosed in the README file.
  • Open-source tools, APIs, and libraries are encouraged, but proper attribution is mandatory. 
  • Teams must cite all third-party resources in their submissions, clearly indicating their sources and how they contributed to the project. 
  • Failure to disclose such information can lead to disqualification. 
  • Any cloned GitHub repositories or pre-existing assets must also be explicitly mentioned in the README, adhering to licensing terms like MIT or GPL. 
  • Pre-designed graphics, icons, and other assets may be used if they comply with Creative Commons or equivalent licensing standards.
  • Development must begin only after the hackathon officially starts at 10 a.m. on Saturday, November 23, 2024. 
  • Teams may brainstorm ideas beforehand but cannot write code prior to the event. 
  • The use of pre-existing libraries and APIs is allowed if properly disclosed. 

GitHub Setup and Organization

The organisers will provide a GitHub repository which must be forked. All work done by teams must be uploaded in their respective fork. Each team's repository must be well organised and conatin the following

  • A README.md file containing project details, technologies used, and citations for any open-source libraries or cloned repositories.
  • A PROGRESS.md file to log updates, challenges, and planned next steps.

Teams are encouraged to follow a structured branching strategy. The main branch should be reserved for production-ready code, the dev branch for active development, and feature-specific branches for tasks such as feature-login or feature-database. All merges into the main branch should occur via pull requests after a code review.

Documentation and Logs

Each project repository must include a well-maintained README.md file with a clear overview of the project, setup instructions, technologies used, and acknowledgments for external contributions. A PROGRESS.md file should document daily progress, challenges faced, and upcoming tasks, ensuring mentors can track the team’s journey and provide assistance when needed.

Workflow and Collaboration

Teams are encouraged to use GitHub Issues for task management, logging bugs, feature requests, and progress updates. Labels like "bug," "feature," or "help wanted" should be used to ensure clarity, with the “Help Needed” label specifically signalling mentors for support. Visualising workflows through GitHub Project Boards with columns such as "To Do," "In Progress," and "Done" is highly recommended. Tools like GitKraken or Sourcetree can aid in visualising branch merges and commit histories.

Progress Tracking and Mentor Engagement

Organizers and mentors will use GitHub Insights to monitor commit frequency, pull requests, and issue resolution. Teams must maintain clear task assignments and provide regular updates in their logs and project boards. Mentors will periodically review activity and offer guidance based on the logged progress and identified bottlenecks.

Good Practices for Development

Clear and concise code commenting is essential, particularly for complex logic or function definitions. Dependency management should include a requirements.txt file listing all necessary libraries and tools, simplifying setup for reviewers and teammates. Regularly testing the environment setup ensures that the README instructions are accurate and complete.

def calculate_area(radius):

    Calculate the area of a circle given its radius.

    Args: 

      radius (float): Radius of the circle.

    Returns: 

      float: Area of the circle.

    """

  return 3.14 * radius * radius

flask==2.2.2

numpy>=1.21.0

pandas==1.5.3

/src # All source code

/tests # Testing scripts

/docs # Documentation files

/assets # Images, videos, or other static assets

/configs # Configuration files (e.g., settings.json, .env)

[README.md](http://README.md) # Project overview and setup guide

[PROGRESS.md](http://PROGRESS.md)

requirements.txt # Dependency list

Organizing the project directory structure is crucial for clarity and efficiency. Suggested organization includes directories for source code (/src), tests (/tests), documentation (/docs), and assets (/assets). Sensitive data, such as API keys, must be excluded using .gitignore.

By following these guidelines, teams can ensure smooth project development, effective collaboration, and compliance with the hackathon rules.

 

 

 

./Judging and Evaluation

 

Stage One: Mid-Hack Check-in (Progress and Ideation)

Participants will be evaluated on their progress and the clarity of their ideation.

 

Stage Two: Final Evaluation

Entries that pass Stage One will proceed to the final evaluation and will be judged based on the following equally weighted criteria:

  1. Functionality
  • Scalability: How well does the application scale for broader use? Can it be adapted for different regions or audiences?
  • API Usage: How effectively are third-party APIs integrated and utilised within the project?
  • Purpose
  • Problem Solving: Is the project addressing a real-world issue? Does the solution have practical utility?
  • Reusability: Would the application encourage users to return? How valuable are its features in the long term?
  • Content
  • Creativity: How innovative is the solution? Does it offer a fresh perspective or new approach?
  • Visual Quality: Is the design visually appealing and functional? Does it enhance the user experience?
  • User Experience
  • Execution: How well is the application developed? Is it intuitive and user-friendly?
  • Accessibility: Is the application easy to navigate and understand by a wide range of users?
  • Technical Execution
  • Code Quality: Is the code clean, efficient, and well-documented?
  • Technical Complexity: How sophisticated is the technical implementation? Does the project push the boundaries of technology?

Elimination Criteria

Entrants providing false information about their identity, contact details, or project ownership, or those found non-compliant with the hackathon rules, will be immediately eliminated from the competition.

Note: These guidelines are subject to change as the hackathon progresses, and further details will be shared closer to the event. Stay tuned for updates!

---

 

./ Code of Conduct and Ethics

 

At ./Dotslash we are committed to fostering an inclusive, harassment-free environment for all participants, regardless of gender, age, sexual orientation, disability, physical appearance, race, or religion. Harassment, discrimination, or any form of offensive behaviour will not be tolerated.

  • All rules on FXP website also apply to Hack participants
  • ⁠All decisions made by FXP/Hackathon staff are final

Examples of prohibited actions include:

  1. Offensive comments or intimidation.
  2. Unwelcome sexual attention or inappropriate physical contact.
  3. Photography or recording without consent.
  4. Disruptive or hostile behaviour during events.

Participants are encouraged to seek help from organisers, mentors, or fellow participants for technical challenges or clarification. However, direct involvement by non-team members in project development, such as coding or designing, is not allowed and may lead to disqualification.

All participants are expected to maintain professionalism and respect throughout the hackathon. Violations may result in immediate expulsion without refund and, if necessary, reporting to authorities. For concerns, contact a staff member immediately. Let's work together to ensure a welcoming and productive event for everyone!

The full code of conduct and general rules can be found here.