Of course! Since I have contributed significantly to the JUnit5 framework, I am most familiar with that project. That’s why I often refer to it in my examples.
1. Issue Labeling In JUnit5, issues are automatically labeled based on their type when they are created. For example, a feature request issue is labeled as “type: new feature.” Additionally, a “status: new” label is applied using GitHub Actions. This allows newcomers reviewing the issue list to immediately understand that the issue is a feature request and is newly created. Furthermore, there are labels like “status: team discussion” for issues requiring internal discussion and “status: blocked” for issues that cannot proceed. These labels help users quickly grasp the current state of the issue. I believe it would be helpful if baremaps could also have automatic labeling based on the type of issue. While project maintainers can manually label issues, labeling itself can be a form of overhead. Adding a few essential labels to reflect the project’s current status would be beneficial. In my opinion, labels like “status: team discussion,” “status: blocked,” and “status: in progress” are essential. Other labels can be discussed and added as needed. 2. Issue Templates https://github.com/apache/incubator-baremaps/issues/334 Like this issue, I noticed that many issues in baremaps are described in a single line. While a single line can be sufficient for conveying information, I think having a structured template could make the process more efficient. Given the nature of the project, providing screenshots or logs might be critical for bug-related issues. Therefore, I suggest creating an issue template that outlines what information users should provide when submitting feature requests or reporting bugs. If there’s interest in adding a template, I can create an issue and submit a PR for it. 3, 4, 5 Currently, I don’t have concrete plans for points 3, 4, and 5. I plan to discuss further with Bertil and develop specific plans afterward. Thank you! Best regards, Yongjun github/yongjun: https://github.com/YongGoose > Hi Yongjun, > > Thank you for sharing these suggestions from the perspective of a new > contributor. > Could you describe the specific changes you’d like to make? > We truly appreciate your contributions:) > > On Sun, Jan 26, 2025 at 12:20 PM 홍용준 <dev.yongj...@gmail.com> wrote: > > > Dear Baremaps Team, > > When I first explore an open-source project, I follow a series of steps > to > > familiarize myself with it. Based on this experience, I have outlined a > few > > suggestions that could enhance the onboarding experience for new > > contributors to the Baremaps project. > > > > 1. > > > > *Issue Labeling* > > > > While browsing the issues, I noticed that recent issues in the > Baremaps > > project lack labels. Categorizing or prioritizing issues with labels > can > > help new contributors quickly understand the context and navigate > > through > > them. > > 2. > > > > *Standardized Templates* > > > > Introducing a detailed and standardized issue template could make the > > project more approachable for contributors. For reference, JUnit5 > > provides > > well-structured issue templates that might serve as a good example: > > JUnit5 Issue Templates > > < > https://github.com/junit-team/junit5/tree/main/.github/ISSUE_TEMPLATE> > > > > Similarly, a pull request (PR) template with a checklist could guide > > contributors before submitting their PRs. This would allow them to > > verify > > key requirements before maintainers review their submissions. For > > reference: > > JUnit5 Pull Request Template > > < > > > https://github.com/junit-team/junit5/blob/main/.github/PULL_REQUEST_TEMPLATE.md > > > > > 3. > > > > *Ideal Issue Management Practices* > > > > Implementing an automated process to tag issues with labels like > > “waiting-for-triage” upon creation could make the issue-triage > workflow > > smoother. Once maintainers review and categorize the issues, > > contributors > > can easily identify the type of issue and engage more effectively. > > 4. > > > > *Improved Documentation* > > > > The existing Getting Started guide is well-written. However, adding > > step-by-step instructions, similar to Apache Kafka’s quickstart guide > > <https://kafka.apache.org/quickstart>, could further enhance its > > usability. > > Alternatively, adopting a dual-track structure like TensorFlow's > > documentation, which caters separately to beginners and advanced > users, > > might also be worth considering: > > TensorFlow Tutorials <https://www.tensorflow.org/tutorials> > > 5. > > > > *Comprehensive User Guide* > > > > While creating a comprehensive user guide may feel resource-intensive, > > it can significantly improve the experience for new users. For > instance, > > JUnit provides an excellent User Guide > > < > > > https://github.com/junit-team/junit5/tree/main/documentation/src/docs/asciidoc/user-guide > > > > > that > > serves as a long-term resource for contributors and users alike. > > > > I understand that some of these suggestions may require considerable time > > and effort to implement. However, they could be considered as part of > > long-term goals to make Baremaps even more accessible to the community. > > Finally, I would like to express my admiration for the incredible work > > behind Baremaps. I am looking forward to contributing consistently to > this > > fantastic project. > > > > Best regards, > > > > Yongjun Hong > > > > > -- > Best wishes！ > CalvinKirs >
