clr-apache commented on code in PR #90: URL: https://github.com/apache/comdev-site/pull/90#discussion_r1140531846
########## source/contributors/becomingacommitter.md: ########## @@ -0,0 +1,93 @@ +--- +title: Becoming a committer +slug: becomingacommitter +-- + +# Disclaimer +Nothing in this post should be construed as a guarantee. You can do everything listed here, for years, and still not become a committer. This is because the decision is made by individuals on the project PMC, who do things for their own reasons. + +On the contrary, this document discusses how things should work, and sometimes do work, in some Apache Software Foundation (ASF) projects, but might not on the one you’re interested in. + +Beneath each of these recommendations is the assumption that you are acting in good faith, for the benefit of the project. Simply attempting to check these boxes to game the system will reflect badly on you, and probably on your employer, too. + +# Becoming a Committer +It’s important to remember that becoming a committer is not a reward, or a recognition, so much as that it is the project expressing self-interest. That is, people are added as a committer to a project because it benefits the project, not because it’s some kind of pat on the back for the individual in question. As such, every behavior suggested here is about advancing the interests of the project. It is critical that you think, first and foremost, about being a project owner, and working towards the benefit of the project and its users. + +These, therefore, are the behaviors that you should exhibit if you want to become a committer, and then a PMC member, on an ASF project. (These are not unique to ASF projects, of course, but process will differ greatly from one project to another, and are largely similar among ASF projects.) + +# Read the mailing list +ASF projects communicate on the mailing list. If you want to be involved in the community, you must set aside time every week (preferably every day) to keep current on the community discussion. + +When first participating in an ASF project, you can (and should) look back several months (or as far as you have time for) to see what has been discussed recently. You can do this at [lists.apache.org](http://lists.apache.org/). + +A growing number of projects also have a presence on Slack, Discord, or somewhere else. Find where that is, and become a regular. A shrinking number of projects have a presence on Libera IRC – mostly the much older projects. This is where you’ll connect with the older members of the projects and learn more of the ancient project lore. + +# Contribute code (and other things) +If you want to become a committer, you should make significant contributions to the project. The most obvious thing to contribute to a software project is code. Code contributions should be diverse in terms of size and significance. That is, you should work on small issues and large. You should collaborate with others on features and fixes, and you should propose significant changes yourself. You should dig up old tickets, and work towards resolving them. + +In particular, you should work on code that is of benefit to all users, rather than focusing solely on features that benefit only yourself, or your employer. As a project owner, you should care about the entire health and sustainability of the project. + +Code contributions are not the only type of contribution that counts towards becoming a committer, it’s just the most common. Design, documentation, marketing, event management, and many other ways of contributing to the success of a project are also often considered in making someone a committer. While the term “committer” implies committing code, it can also be interpreted as someone who is committed to the project. + +# End user support +Answering end user questions has many benefits. It’s the best way to establish expertise in aspects of the software that effect actual users, and, thus, the best way to stay in touch with user concerns. It’s also the way to establish and maintain visibility in the project community, because your name is always visible on the mailing list. + +Caution: Do not just jump in and answer every question with visibility as a primary goal. Ensure that your answers are actually useful, and contribute something to the conversation. Simply posting to every conversation, particularly when someone else has already offered a good answer, can be perceived as attempting to game the metrics. + +# Documentation +Improving the documentation is one of the most effective things that one can do to improve the user experience. If you notice many people asking similar questions, this is usually an indication that the documentation is weak on that point. Fix it. When the question is asked again, point to the improved documentation, and ask for feedback as to how it could be further improved. + +Take criticism of the documentation as a challenge, rather than a personal criticism. + +# Review PRs and tickets +Dig into unmerged PRs and outstanding tickets. Figure out how to navigate the process to get an old ticket resolved, or a PR merged. + +This is an investment in the project in two ways. + +The obvious improvement is getting an issue fixed or a PR merges, thus enhancing the project. The less obvious way is that ancient tickets, and unmerged PRs, communicate that the project is not actively maintained, and that user issues are being ignored. This undermines project trust. Thus, addressing these things builds community trust, and increases your personal value to the project. Review Comment: s/merges/merged/ ########## source/contributors/becomingacommitter.md: ########## @@ -0,0 +1,93 @@ +--- +title: Becoming a committer +slug: becomingacommitter +-- + +# Disclaimer +Nothing in this post should be construed as a guarantee. You can do everything listed here, for years, and still not become a committer. This is because the decision is made by individuals on the project PMC, who do things for their own reasons. + +On the contrary, this document discusses how things should work, and sometimes do work, in some Apache Software Foundation (ASF) projects, but might not on the one you’re interested in. + +Beneath each of these recommendations is the assumption that you are acting in good faith, for the benefit of the project. Simply attempting to check these boxes to game the system will reflect badly on you, and probably on your employer, too. + +# Becoming a Committer +It’s important to remember that becoming a committer is not a reward, or a recognition, so much as that it is the project expressing self-interest. That is, people are added as a committer to a project because it benefits the project, not because it’s some kind of pat on the back for the individual in question. As such, every behavior suggested here is about advancing the interests of the project. It is critical that you think, first and foremost, about being a project owner, and working towards the benefit of the project and its users. + +These, therefore, are the behaviors that you should exhibit if you want to become a committer, and then a PMC member, on an ASF project. (These are not unique to ASF projects, of course, but process will differ greatly from one project to another, and are largely similar among ASF projects.) + +# Read the mailing list +ASF projects communicate on the mailing list. If you want to be involved in the community, you must set aside time every week (preferably every day) to keep current on the community discussion. + +When first participating in an ASF project, you can (and should) look back several months (or as far as you have time for) to see what has been discussed recently. You can do this at [lists.apache.org](http://lists.apache.org/). + +A growing number of projects also have a presence on Slack, Discord, or somewhere else. Find where that is, and become a regular. A shrinking number of projects have a presence on Libera IRC – mostly the much older projects. This is where you’ll connect with the older members of the projects and learn more of the ancient project lore. + +# Contribute code (and other things) +If you want to become a committer, you should make significant contributions to the project. The most obvious thing to contribute to a software project is code. Code contributions should be diverse in terms of size and significance. That is, you should work on small issues and large. You should collaborate with others on features and fixes, and you should propose significant changes yourself. You should dig up old tickets, and work towards resolving them. + +In particular, you should work on code that is of benefit to all users, rather than focusing solely on features that benefit only yourself, or your employer. As a project owner, you should care about the entire health and sustainability of the project. + +Code contributions are not the only type of contribution that counts towards becoming a committer, it’s just the most common. Design, documentation, marketing, event management, and many other ways of contributing to the success of a project are also often considered in making someone a committer. While the term “committer” implies committing code, it can also be interpreted as someone who is committed to the project. + +# End user support +Answering end user questions has many benefits. It’s the best way to establish expertise in aspects of the software that effect actual users, and, thus, the best way to stay in touch with user concerns. It’s also the way to establish and maintain visibility in the project community, because your name is always visible on the mailing list. + +Caution: Do not just jump in and answer every question with visibility as a primary goal. Ensure that your answers are actually useful, and contribute something to the conversation. Simply posting to every conversation, particularly when someone else has already offered a good answer, can be perceived as attempting to game the metrics. + +# Documentation +Improving the documentation is one of the most effective things that one can do to improve the user experience. If you notice many people asking similar questions, this is usually an indication that the documentation is weak on that point. Fix it. When the question is asked again, point to the improved documentation, and ask for feedback as to how it could be further improved. + +Take criticism of the documentation as a challenge, rather than a personal criticism. + Review Comment: As you learn about the project, consider yourself a tester of the documentation. If anything is unclear, propose a patch. ########## source/contributors/becomingacommitter.md: ########## @@ -0,0 +1,93 @@ +--- +title: Becoming a committer +slug: becomingacommitter +-- + +# Disclaimer +Nothing in this post should be construed as a guarantee. You can do everything listed here, for years, and still not become a committer. This is because the decision is made by individuals on the project PMC, who do things for their own reasons. + +On the contrary, this document discusses how things should work, and sometimes do work, in some Apache Software Foundation (ASF) projects, but might not on the one you’re interested in. + +Beneath each of these recommendations is the assumption that you are acting in good faith, for the benefit of the project. Simply attempting to check these boxes to game the system will reflect badly on you, and probably on your employer, too. + +# Becoming a Committer +It’s important to remember that becoming a committer is not a reward, or a recognition, so much as that it is the project expressing self-interest. That is, people are added as a committer to a project because it benefits the project, not because it’s some kind of pat on the back for the individual in question. As such, every behavior suggested here is about advancing the interests of the project. It is critical that you think, first and foremost, about being a project owner, and working towards the benefit of the project and its users. + +These, therefore, are the behaviors that you should exhibit if you want to become a committer, and then a PMC member, on an ASF project. (These are not unique to ASF projects, of course, but process will differ greatly from one project to another, and are largely similar among ASF projects.) + +# Read the mailing list +ASF projects communicate on the mailing list. If you want to be involved in the community, you must set aside time every week (preferably every day) to keep current on the community discussion. + +When first participating in an ASF project, you can (and should) look back several months (or as far as you have time for) to see what has been discussed recently. You can do this at [lists.apache.org](http://lists.apache.org/). + +A growing number of projects also have a presence on Slack, Discord, or somewhere else. Find where that is, and become a regular. A shrinking number of projects have a presence on Libera IRC – mostly the much older projects. This is where you’ll connect with the older members of the projects and learn more of the ancient project lore. + +# Contribute code (and other things) +If you want to become a committer, you should make significant contributions to the project. The most obvious thing to contribute to a software project is code. Code contributions should be diverse in terms of size and significance. That is, you should work on small issues and large. You should collaborate with others on features and fixes, and you should propose significant changes yourself. You should dig up old tickets, and work towards resolving them. + +In particular, you should work on code that is of benefit to all users, rather than focusing solely on features that benefit only yourself, or your employer. As a project owner, you should care about the entire health and sustainability of the project. + +Code contributions are not the only type of contribution that counts towards becoming a committer, it’s just the most common. Design, documentation, marketing, event management, and many other ways of contributing to the success of a project are also often considered in making someone a committer. While the term “committer” implies committing code, it can also be interpreted as someone who is committed to the project. + +# End user support +Answering end user questions has many benefits. It’s the best way to establish expertise in aspects of the software that effect actual users, and, thus, the best way to stay in touch with user concerns. It’s also the way to establish and maintain visibility in the project community, because your name is always visible on the mailing list. + +Caution: Do not just jump in and answer every question with visibility as a primary goal. Ensure that your answers are actually useful, and contribute something to the conversation. Simply posting to every conversation, particularly when someone else has already offered a good answer, can be perceived as attempting to game the metrics. + +# Documentation +Improving the documentation is one of the most effective things that one can do to improve the user experience. If you notice many people asking similar questions, this is usually an indication that the documentation is weak on that point. Fix it. When the question is asked again, point to the improved documentation, and ask for feedback as to how it could be further improved. + +Take criticism of the documentation as a challenge, rather than a personal criticism. + +# Review PRs and tickets +Dig into unmerged PRs and outstanding tickets. Figure out how to navigate the process to get an old ticket resolved, or a PR merged. + +This is an investment in the project in two ways. + +The obvious improvement is getting an issue fixed or a PR merges, thus enhancing the project. The less obvious way is that ancient tickets, and unmerged PRs, communicate that the project is not actively maintained, and that user issues are being ignored. This undermines project trust. Thus, addressing these things builds community trust, and increases your personal value to the project. + +# Be visible +Participate meaningfully in discussions on the developer mailing list. Drive discussions through to action. Advocate for changes that help yourself and your employer, but also for those that improve the project as a whole. + +Get to know the important characters on the project, and what their priorities are. Help them achieve those priorities in whatever way you can. Figure out who you can best collaborate with to advance your own personal interests in the project, but also the overall health of the project and community. + +Start conversations around topics you’re passionate about, and volunteer to be the one to address them. + +Do not, however, just talk to be seen. Nobody is fooled by that. + Review Comment: # Review/Improve Continuous Integration testing Many projects use CI to continuously test proposed patches and PRs. Each platform needs to be individually set up for testing, and often the projects do not have enough people familiar with the specific environments that might benefit from testing. You can propose additional platforms to test on -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
