Contributing
If you are new and want to pick up a ticket, you will not be able to as you are not part of the organisation. Please comment on the ticket with your intent of wanting to work on it. @javadiscord/maintainers can then assign the ticket to you.
When picking up a ticket, choose one that's in the "Ready" column. These are tickets that can be picked up. They are ordered by priority i.e. the first tickets are most important. You do have the freedom to pick up any ticket in any priority which you may enjoy or if that ticket suits your skill set.
When you start working on a ticket to link your PR back to the ticket, within the ticket itself you can either:
-
Create a branch through the ticket
-
Link your branch to the ticket by clicking on the "Development" heading
What do we mean when we say a ticket is "Done"?
The definition of done (DoD) is when all conditions, or acceptance criteria are met and ready to be accepted. We must meet the definition of done to ensure quality. It lowers rework, by preventing tasks that don’t meet the definition from being merged to main. It will prevent features that don’t meet the definition from being delivered to the end user.
The following is a guideline and you should use your own initiative when considering a piece of work done.
- The task has been completed to the best ability of a developer. This means the context has been considered in the implementation and covered to the scope of the ticket.
- The PR(s) raised as part of ticket cover what has been defined in the Acceptance Criteria
- The build and unit tests are passing.
- Adequate testing has been performed to ensure the work conducted is functioning as expected.
- The PR has been code reviewed by at least 1 of the maintainers
Code review is a crucial aspect of the software development process. It helps maintain code quality, ensures adherence to coding standards, and fosters collaboration among team members. Effective code review requires a structured approach and adherence to certain guidelines to ensure its efficiency and effectiveness. Below are some key principles and best practices for conducting code reviews:
Before diving into the review process, it's essential to understand the purpose of the code review. The primary objectives of code review include:
- Improving Code Quality: Identifying and fixing bugs, enhancing readability, and ensuring adherence to coding standards.
- Knowledge Sharing: Facilitating knowledge transfer among team members by discussing design decisions, implementation approaches, and best practices.
- Maintaining Consistency: Ensuring consistency in coding style, architecture, and design patterns across the codebase.
- Preventing Defects: Catching potential issues early in the development lifecycle, thus reducing the cost of fixing defects later.
During code review, it's essential to focus on objective criteria rather than personal preferences or opinions. Some objective criteria to consider include:
- Coding Standards: Ensure that the code follows the established coding standards and guidelines of the project.
- Performance: Check for potential performance bottlenecks, inefficient algorithms, or resource-intensive operations.
- Security: Be vigilant for potential vulnerabilities, this is a user facing library and we should be looking out for potential security concerns.
- Functionality: Verify that the code behaves as intended and meets the specified requirements.
- Error Handling: Ensure proper error handling mechanisms are in place to gracefully handle exceptions and edge cases.
When providing feedback during a code review, focus on constructive criticism aimed at improving the code quality rather than criticizing the developer personally. Some tips for providing constructive feedback include:
- Be Specific: Clearly identify the issues or areas for improvement, providing specific examples and suggestions for improvement.
- Stay Positive: Use positive language and tone to encourage the developer and maintain a positive atmosphere.
- Offer Solutions: Instead of just pointing out problems, offer suggestions or alternatives for improvement.
- Acknowledge the Positive: Recognize and acknowledge the strengths and good practices in the code, in addition to highlighting areas for improvement.
Avoid the temptation to micromanage or nitpick every aspect of the code. Trust the developer's expertise and judgment unless there are significant issues or violations of coding standards. Remember that code review is a collaborative process, not an opportunity for the reviewer to rewrite the code according to their preferences.
Code review should be a collaborative effort aimed at improving code quality and fostering learning and growth among team members. Encourage open discussions, knowledge sharing, and peer learning during code reviews. Emphasize the importance of mutual respect, empathy, and constructive communication among team members.
Utilize code review tools and platforms to streamline the code review process, track changes, and manage feedback. GitHub provides some excellent ways to make changes in a review for example using the Suggested Changes option.
If someone suggests changes to your pull request and the changes are out of the pull request's scope, you can open a new issue to track the feedback.
Effective code review is essential for maintaining code quality, fostering collaboration, and ensuring the overall success of the project. By following the guidelines outlined above and adopting a structured approach to code review, teams can maximize the benefits of code review and deliver high-quality software products. Remember that code review is not just about finding defects but also about improving code quality, sharing knowledge, and growing as a team.