April 29, 2019 at 13:28How to quickly inject pools into upstream?
Friends, today I want to tell you about one idea that has long settled in my head. It arose many years ago and its purpose is to make a service that aggregates and presents in a convenient form all the communications occurring around GitHub projects that interest you. Such a service will be first of all very useful for those who have many of their projects on GitHub, or those who create many pulls and tickets in other people's projects.
I believe that people who create tickets and pulls do this in order to improve those open source projects that they care about. And for this it is necessary that the tickets turn into pulls and pulls timely merge. The faster this process takes place, the faster OpenSource will evolve.
However, on GitHub it often happens that the communication around the ticket or pull is silent and lost. This happens for various reasons, but as a rule - due to the fact that some of the participants skips the email-jab about the comment. The reasons can be different, but the result is always the same - the ticket is lost and sometimes years pass before they remember it.
Of course, the github provides for this case pages with a list of pulls (https://github.com/pulls) and tickets (https://github.com/issues), but in my opinion they are inconvenient in that they do not give the slightest hint on which of the tickets requires a reaction from you, and in which not. This is what I want to fix.
My project, 12forks.com, will provide an experimental interface for working with tickets and pulls. This is an interface in which it will be possible to look at one page to understand in which tickets you are expected to receive an answer, in which pool you need to fix the merge-conflict, and where to call the maintainer, because it doesn’t react for a long time. Perhaps there will also be integration with various messengers like Slack or Telegram. The point is to speed up communication and problem solving in Opensource projects.
I already use the MVP of this tool, which works while in the console. With its help, in a few days it was possible to halve the “blockage” of 103 pulls and tickets. I just closed the part after the prescription of years. And in some cases, it is clearly seen that delays between comments can be years:
I believe that such a tool can speed up the process of making changes and will be useful to anyone who wants to contribute to OpenSource.
According to my estimates, about 3% of all users of the github are actively working with tickets and pulls, and three percent of the 48 million (that’s how much I calculated in my research) is almost one and a half million people. That is how many people can potentially benefit from the solution I invented.
According to the plan, the publicly available MVP will be ready in June. If you are interested in becoming one of the first to start using it, leave your email by filling out the form at 12forks.com
Also, I really look forward to any ideas that you could try in a similar product. Write them in the comments on this post, or by email at ideas@12forks.com.
I believe that people who create tickets and pulls do this in order to improve those open source projects that they care about. And for this it is necessary that the tickets turn into pulls and pulls timely merge. The faster this process takes place, the faster OpenSource will evolve.
However, on GitHub it often happens that the communication around the ticket or pull is silent and lost. This happens for various reasons, but as a rule - due to the fact that some of the participants skips the email-jab about the comment. The reasons can be different, but the result is always the same - the ticket is lost and sometimes years pass before they remember it.
Of course, the github provides for this case pages with a list of pulls (https://github.com/pulls) and tickets (https://github.com/issues), but in my opinion they are inconvenient in that they do not give the slightest hint on which of the tickets requires a reaction from you, and in which not. This is what I want to fix.
My project, 12forks.com, will provide an experimental interface for working with tickets and pulls. This is an interface in which it will be possible to look at one page to understand in which tickets you are expected to receive an answer, in which pool you need to fix the merge-conflict, and where to call the maintainer, because it doesn’t react for a long time. Perhaps there will also be integration with various messengers like Slack or Telegram. The point is to speed up communication and problem solving in Opensource projects.
I already use the MVP of this tool, which works while in the console. With its help, in a few days it was possible to halve the “blockage” of 103 pulls and tickets. I just closed the part after the prescription of years. And in some cases, it is clearly seen that delays between comments can be years:
I believe that such a tool can speed up the process of making changes and will be useful to anyone who wants to contribute to OpenSource.
According to my estimates, about 3% of all users of the github are actively working with tickets and pulls, and three percent of the 48 million (that’s how much I calculated in my research) is almost one and a half million people. That is how many people can potentially benefit from the solution I invented.
According to the plan, the publicly available MVP will be ready in June. If you are interested in becoming one of the first to start using it, leave your email by filling out the form at 12forks.com
Also, I really look forward to any ideas that you could try in a similar product. Write them in the comments on this post, or by email at ideas@12forks.com.