How to quickly put the pool in upstream?
Friends, today I want to tell you about one idea that has long been settled in my head. It originated many years ago and its purpose is to make a service that would aggregate and present in a convenient way all the communications occurring around GitHub projects of interest to you. Such a service will be first of all very useful to those who have a lot of their projects on GitHub, or those who create a lot of pull and tickets in other people's projects.
I believe that people who create tickets and pulluli do this in order to improve those opensource projects that they care about. And for this, it is necessary for tickets to turn into pull and pull in time merdzhili. The faster this process takes place, the faster OpenSource will develop.
However, on GitHub it is often the case that communication around a ticket or pull subsides and is lost. This happens for various reasons, but as a rule, due to the fact that some of the participants skip the email-beating about the comment. The reasons may be different, but the result is always the same - the ticket is lost and sometimes years pass before they remember about it.
Of course, the githab provides for such a case a page with a list of pull (https://github.com/pulls) and tickets (https://github.com/issues), but in my opinion they are inconvenient because they do not give the slightest hint on which of the tickets you are required to respond to, and which not. This is what I want to fix.
')
My project - 12forks.com, will provide an experimental interface for working with tickets and pull. Such an interface, in which it will be possible, looking at one page, to understand which tickets are waiting for an answer from you, in which pool you need to fix the merge-conflict, and where to call the maintender, because it doesn’t react for a long time. It may also be the integration with different 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 is still in the console. With it, in a few days we managed to halve the “blockage” of 103 pull and tickets. I just closed the part for years. And in some cases, it can be clearly seen that the delay 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, approximately 3% of all github users work actively with tickets and pullas, and three percent of the 48 million (I counted that in my research), this is almost half a million people. So many people can potentially benefit from the solution I have invented.
According to the plan, 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, really looking forward to any ideas that could be tried in a similar product. Write them in the comments to this post, or email ideas@12forks.com.
I believe that people who create tickets and pulluli do this in order to improve those opensource projects that they care about. And for this, it is necessary for tickets to turn into pull and pull in time merdzhili. The faster this process takes place, the faster OpenSource will develop.
However, on GitHub it is often the case that communication around a ticket or pull subsides and is lost. This happens for various reasons, but as a rule, due to the fact that some of the participants skip the email-beating about the comment. The reasons may be different, but the result is always the same - the ticket is lost and sometimes years pass before they remember about it.
Of course, the githab provides for such a case a page with a list of pull (https://github.com/pulls) and tickets (https://github.com/issues), but in my opinion they are inconvenient because they do not give the slightest hint on which of the tickets you are required to respond to, and which not. This is what I want to fix.
')
My project - 12forks.com, will provide an experimental interface for working with tickets and pull. Such an interface, in which it will be possible, looking at one page, to understand which tickets are waiting for an answer from you, in which pool you need to fix the merge-conflict, and where to call the maintender, because it doesn’t react for a long time. It may also be the integration with different 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 is still in the console. With it, in a few days we managed to halve the “blockage” of 103 pull and tickets. I just closed the part for years. And in some cases, it can be clearly seen that the delay 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, approximately 3% of all github users work actively with tickets and pullas, and three percent of the 48 million (I counted that in my research), this is almost half a million people. So many people can potentially benefit from the solution I have invented.
According to the plan, 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, really looking forward to any ideas that could be tried in a similar product. Write them in the comments to this post, or email ideas@12forks.com.
Source: https://habr.com/ru/post/449972/
All Articles