You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do you support an idea to create a new GitHub organization to facilitate community efforts and move forward?
If you simply support the idea without further explanations, vote Create a new GitHub organization. If you don't, please read below for the reason why I am proposing and vote Keep everything as is. If you have a different idea, choose I have a different idea AND propose your idea in Discussion.
Problem description
IIRC, I am the sole committer other than @UncleRus. I can commit and merge but nothing else. For example, I cannot:
add new GitHub secrets to integrate GitHub Actions with external services, including espressif's Library Repository
invite someone to delegate works to maintain the repository
modify security policies to allow and/or deny certain actions in GitHub Actions
prove the ownership of the repository for third-party integration
As a result, #549 cannot be resolved. It is not practically possible to divide the project into smaller, independent projects. In addition, the project will halt when a bus hit me one day.
Potential risks and benefits
Here is a list of potential risks and benefits, which allows you to make an informed decision.
Risk: Malicious user can potentially cause harm on the code, thus, on your products
Some of you might maintain a private or public fork of the repository. According to Insights, there are several public forks. Some are purely for experimenting new code and creating PRs, but others are for specific enhancements or drivers they privately maintain for their own products. That is totally fine. However, the more forks that enhance the code or fix specific issues, the more probability of malicious code sneaks in to your code. For example, a fork claims that it has a new driver for a device. The fork claims that the code is not merged because the original project halted. Some might think that the fork would help their projects without realizing the fork has a backdoor or other harmful code. This is not a theoretical issue, it is happening everywhere.
Well, it might sound like a valid reason to move to an organization. However, multiple owners and more contributors with access rights would increase the risk as well. If you haven't read the Timeline of the xz open source attack, you should. There is no silver bullet for this issue that I can think of. Mutual monitoring and active community might prevent some issues, but they are certainly not perfect solutions.
Risk: Multiple repositories can cause confusions
When a community forks and the old code will not be maintained, the repository is often archived. It is a clear sign to tell potential users to look elsewhere.
As I do not have full access rights, the repository cannot be archived. Instead, the README.md would have a disclaimer or an announcement, which tells the users the fact, that is, there is a fork, and explains why. That is all what I can do. Still, some users will not notice it or others might be confused to choose which repository to use.
Benefit: Facilitating more community efforts drives the project forward
As stated in the Problem description, the move would enable us to solve the issues we are facing. The situation around me is slightly better than before but not good enough to spend lots of time on the project. Thankfully, we still have active contributors to help the project. I would like to see more. A typical bar to jump across when you contribute to projects is on-boarding. I wrote CONTRIBUTING.md but it can be better in many ways. If we improve the process and see more contributors, the project would drive itself into a better direction.
Benefit: Multiple project owners improves sustainability of the project
When a bus hit me, the project will halt completely.
It is always sad to see halted FOSS projects. It even hurts when you are using them in your products. The reasons may vary, such as lack of interest, lack of resources, or whatever. Whenever it happens, you might be able to switch to another project. However, that will not improve the sustainability of your products because you are not improving the sustainability of FOSS. The root cause of the issue is, FOSS projects are not sustainable without proper, healthy contributions from community. These days, you cannot live without FOSS code. This xkcd comic clearly illustrates the issue.
Just a few project owners will not solve the issue, though. It would take many, not a few, to improve the sustainability. However, that would be a huge improvement over the current situation. I am not 100% sure about how to invite someone yet, but we will see.
Conclusion
I cannot maintain the project without your help. I would continue what I have been doing if the majorities choose "No" because that is what I can for the moment. If you would like to see more drivers, improvements, or bug fixes, please support the project.
Thanks for reading. Now, it's time to have your voice heard. Please choose one of the options below.
Do you support an idea to create a new GitHub organization?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
Do you support an idea to create a new GitHub organization to facilitate community efforts and move forward?
If you simply support the idea without further explanations, vote
Create a new GitHub organization
. If you don't, please read below for the reason why I am proposing and voteKeep everything as is
. If you have a different idea, chooseI have a different idea
AND propose your idea in Discussion.Problem description
IIRC, I am the sole committer other than @UncleRus. I can commit and merge but nothing else. For example, I cannot:
add new GitHub secrets to integrate GitHub Actions with external services, including espressif's Library Repository
invite someone to delegate works to maintain the repository
modify security policies to allow and/or deny certain actions in GitHub Actions
prove the ownership of the repository for third-party integration
As a result, #549 cannot be resolved. It is not practically possible to divide the project into smaller, independent projects. In addition, the project will halt when a bus hit me one day.
Potential risks and benefits
Here is a list of potential risks and benefits, which allows you to make an informed decision.
Risk: Malicious user can potentially cause harm on the code, thus, on your products
Some of you might maintain a private or public fork of the repository. According to Insights, there are several public forks. Some are purely for experimenting new code and creating PRs, but others are for specific enhancements or drivers they privately maintain for their own products. That is totally fine. However, the more forks that enhance the code or fix specific issues, the more probability of malicious code sneaks in to your code. For example, a fork claims that it has a new driver for a device. The fork claims that the code is not merged because the original project halted. Some might think that the fork would help their projects without realizing the fork has a backdoor or other harmful code. This is not a theoretical issue, it is happening everywhere.
Well, it might sound like a valid reason to move to an organization. However, multiple owners and more contributors with access rights would increase the risk as well. If you haven't read the Timeline of the xz open source attack, you should. There is no silver bullet for this issue that I can think of. Mutual monitoring and active community might prevent some issues, but they are certainly not perfect solutions.
Risk: Multiple repositories can cause confusions
When a community forks and the old code will not be maintained, the repository is often archived. It is a clear sign to tell potential users to look elsewhere.
As I do not have full access rights, the repository cannot be archived. Instead, the README.md would have a disclaimer or an announcement, which tells the users the fact, that is, there is a fork, and explains why. That is all what I can do. Still, some users will not notice it or others might be confused to choose which repository to use.
Benefit: Facilitating more community efforts drives the project forward
As stated in the Problem description, the move would enable us to solve the issues we are facing. The situation around me is slightly better than before but not good enough to spend lots of time on the project. Thankfully, we still have active contributors to help the project. I would like to see more. A typical bar to jump across when you contribute to projects is on-boarding. I wrote CONTRIBUTING.md but it can be better in many ways. If we improve the process and see more contributors, the project would drive itself into a better direction.
Benefit: Multiple project owners improves sustainability of the project
When a bus hit me, the project will halt completely.
It is always sad to see halted FOSS projects. It even hurts when you are using them in your products. The reasons may vary, such as lack of interest, lack of resources, or whatever. Whenever it happens, you might be able to switch to another project. However, that will not improve the sustainability of your products because you are not improving the sustainability of FOSS. The root cause of the issue is, FOSS projects are not sustainable without proper, healthy contributions from community. These days, you cannot live without FOSS code. This xkcd comic clearly illustrates the issue.
Just a few project owners will not solve the issue, though. It would take many, not a few, to improve the sustainability. However, that would be a huge improvement over the current situation. I am not 100% sure about how to invite someone yet, but we will see.
Conclusion
I cannot maintain the project without your help. I would continue what I have been doing if the majorities choose "No" because that is what I can for the moment. If you would like to see more drivers, improvements, or bug fixes, please support the project.
Thanks for reading. Now, it's time to have your voice heard. Please choose one of the options below.
5 votes ·
Beta Was this translation helpful? Give feedback.
All reactions