I've created two issues. Feel free to share any feedback!
If everything looks good, I'll start working on them right away. - https://github.com/apache/incubator-baremaps/issues/925 - https://github.com/apache/incubator-baremaps/issues/926 Best Regards, Yongjun > Automatically closing issues or pull requests that haven’t had updates for > a long time could be an effective solution. I believe using stale could be > a great way to handle this. > > stale: https://github.com/actions/stale > > This week is a national holiday in Korea, so I might not have much time to > work.🥲 Once the PR I’m currently working on gets merged, I’ll start > working on the template as you suggested! > > Thank you! > > Best regards, > > Yongjun > > [image: image.gif] > >> >> I’ be interested in using template to see if it helps gathering more >> information. However, we should keep in mind that the nature of the issues >> may vary greatly in Apache Baremaps. For instance, we may have styling >> issues in the basemap (in which case we need coordinates, a screenshot and >> browser information) or bugs in codecs (in which case we’d prefer to have a >> problematic file that allows us to reproduce the issue, a command, or a >> test case). >> >> We could start with a high-level template asking for as many information >> as possible and see where it takes us. E.g.: >> - Description >> - Environment >> - Steps to reproduce >> - Attachments (data and screenshots) >> >> Additionally, we should keep in mind that some feature requests don’t >> necessarily need to be implemented. For instance, #334 was created a long >> time ago and can be addressed by starting another jvm process for another >> tileset. Until now, I assume nobody needed it urgently enough to implement >> it. Perhaps we should close these issues and leave a comment so the author >> can push for it again if it is really necessary. This approach would allow >> us to keep the issue tracker in a cleaner state and to have a clearer >> roadmap (where we want the project to go). What do you think? >> >> Regarding the diagrams, Mermaid is a good option on GitHub. We used it >> for the data module, and it is welcome for documenting other parts of the >> project. The main challenge is likely keeping them up to date as the >> project evolves. >> https://github.com/apache/incubator-baremaps/tree/main/baremaps-data >> >> Best, >> >> Bertil >> >> > On 27 Jan 2025, at 00:19, Yongjun Hong <dev.yongj...@gmail.com> wrote: >> > >> > Additionally, leveraging PlantUML to visualize the dependencies and >> interactions between the modules in Baremaps could be a great way to >> provide clarity. >> > For example, we could draw like JUnit 5: >> https://github.com/junit-team/junit5/blob/main/documentation/src/plantuml/component-diagram.puml >> > >> > I’d appreciate your feedback on my ideas. >> > >> > Best regards, >> > >> > Yongjun >> > >> > >> > >> >> >> >> 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 <mailto: >> 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 >> >>
