-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FYI] Why pull requests in this repo aren't processed timely, a case study, was: More help #27
base: master
Are you sure you want to change the base?
Conversation
enhanced version of: pfalcon#22
Thanks, I appreciate desire to help. Please see https://eli.thegreenplace.net/2019/how-to-send-good-pull-requests-on-github/ for typical guidelines for pull request submission to projects. Hopefully that explains why this and other PRs in this repo can't be processed without noticeable cleanups, so they're waiting for those cleanups. |
Yes, this PR is big and must be splitted, I know that, too... I spared the extra effort. Because the other PR aren't merged. And #23 #21 #20 are needed to use this project. These PRs are IMHO ready for merged, but not done, yet and no comment why. Maybe another needfull patch is: ulno@566a292 But I don't know that for sure. Because of this and many other open/not commented issued, the project looks unmaintained to me. I therefore come to the conclusion that it would be best if this project was included in micropython repro. In the hope that it will be easier for everyone to use: micropython/micropython#2535 (comment) |
Ok, as I effectively find myself doing the same what you're doing here, @jedie (arguing for revival of another project). So, I feel obliged to respond here either. Actually, I'm a firm believer that one open-source developer can call to another one for answers and get one (and I checked that you @jedie have an open-source participation history, because fairly speaking, communication with random passer-by's is getting unsustainable here on github). Let's however get the obvious things straight. Not merging pull requests is not good, aka bad. And the reasons for that would be bad themselves, how otherwise? And talking about bad things is unpleasant. And yet you call for answers (in preference of silence), you want to open that Pandora box. Apologies in advance if you find some things not exactly pleasant. Ok, to give a glimpse of the things we're going to talk about, let's see how us 2 met. You sent me a Hmm - how to put it more politely - my language and grammar teacher never suggested to title letters to unfamiliar people in such a way. Neither grown-up people with whom I normally communicate write their letters in such a way, unless they want to achieve a peculiar effect. So, if you wanted to achieve one, congrats, it worked. Don't get me wrong - I'm not trying to teach you how to write, do however you like. But neither you will be able to teach somebody else, and the world in general, how to read. And if you never thought how it works, let's do it together: people open their mail client (or bug tracker, doesn't matter) and see titles of messages. Some descriptive, detailed, and clear, some are "?!!!???!!11". What matters is that there're many of them, e.g. I receive ~50 mail every day (most are notifications of some activity course). In no way I'll be able to read them all - I pick up a few to deal with immediately, and leave the rest for "later", whenever that may come. So, thanks again for helping to prioritize your submissions by giving them suitable title. (E.g., if you want delays with response, please keep up with "Tutorial ?!?", "More help", etc.) (To be continued.) |
Hm. So this is about the subject line, not the content? If the subject line is not well chosen, it goes into trash and fine? Sorry, i'm not a native English speaker. Even worse, my English is very bad. I guess you can notice that too, right? Let's not talk about wording. Let's talk about how to improve this project. When I look at existing issues, it should be clear that not only I wonder how to use it. But it doesn't matter now. I've come further. Can build it halfway now. |
Ok, status of the project. To understand it, you need to know history of the project. It's all out there, as you found by doing modest amount of searching around. But let me provide condensed summary.
Yeah, that's it. And just imagine - if you came some 3 years before, we'd have such a great development party! (Or maybe if I came some 3 years later, but this is my story, and I tell it from my point of view.) Or maybe we'd not. Because none of my repositories contain commits titled like "needed bugfix from <foobar>" or "fixup!". None commits in my repositories say that they "remove website", and actually start with removing the tests. Please find differences between https://github.com/pfalcon/yaota8266/commits/master and https://github.com/pfalcon/yaota8266/pull/27/commits . And if you don't see them, well, d'oh, it will be hard to explain. Suffice to say that whole of my programming experience (and I'm not exactly young) calls to not do it like in examples outside my humble repo, and do it like I do it inside my repos (and I'm not perfect in any way and there's room for improvement). So, that's it, the pretty-obvious-to-all-git-users golden rule of thumb: do *1 There're exceptions to everything. Also, exceptions are exceptions. Don't start with exceptions, that's confusing. |
Our story is now told. Dry residue:
Thanks again for the desire to review/help it, and Happy New Year! |
But no, as I explained, it stays in the backlog queue. And that's not fine, what if content was important?
Sorry, I can't ;-). Probably because I'm not native English speaker myself ;-). |
I will close this, because i made #28 with a better branch name... |
I would prefer this issue to stay up and be discoverable by interested parties, I won't be able to go thru the exercise of repeating the points above again and again. (It of course applies to many other projects, mine or not.) |
And - meet another open-source micro-tragedy of the commons du jour: pyinstaller/pyinstaller#4404 Some quotes:
Don't get me wrong - the common thing between this and that (and many other projects) is that they are/will be not actively maintained, and not something else. But the underlying reason why some person maintains something is: a) they personally need that, or b) they have customers for that. There're unfortunately no other foundations for sustainable maintenance otherwise. Likewise, the way a particular project is maintained is based on: a) customers' requirements/desires, backed by appropriate resources of course; b) maintainers' own rules. In both cases, contributors just need to follow them. |
Now a good example of well-specified contribution policy: https://github.com/soimort/you-get/blob/develop/CONTRIBUTING.md
So, if you want to report an issue, you need to submit a PR. With specific requirement. And it's well specified what happens if you don't. A good example how projects with almost 30K stars cope with their "success", and what they do to prevent their maintainers' lives turning into complete misery. |
The essential thing is that you do not want to maintain the project any further, isn't it? That's totally okay and understandable. Maintaining a project takes time and we all definitely don't have enough of it ;) And if you don't use yaota8266 at the moment then it's even more understandable. The other topic "which pull requests are accepted" is totally irrelevant as long as you do not maintain the project. |
But no, of course no, like clearly explained above (so this is last time I repeat it) - of course I want to maintain it! I also want to climb Himalaya and fly to Mars, don't even ask. I just don't have time and other resources to do that right now. My resources are finite, so I need to plan them carefully, and currently other projects prevail.
It's absolutely relevant, because for projects actively maintained at the specific time, I (or any other maintainers) still have finite resources and again face a choice: either spend time of their lives on cleaning up stuff dropped by other folks, or do something different, perhaps even more exciting, and leave cleanup to the folks who produced that stuff (or maybe some volunteers, or maybe someone will pay maintainers to do that). So, I'm mostly concerned how to make this point clear, unambiguous, and ultimately positive to the project itself and all participants in it. |
So it's de facto currently unmaintained in my eyes. So the work to make pull requests nicer are in vain. I am not talking about my huge pull requests to make this project easier useable. e.g. the small bugfixes without this project can't be used. For example: #23 or #21 But let's stop discussing it. It's a waste of time that could be better spent implementing code ;) |
If making things nicer is against your will, then yes. But for some people who never thought that making changes could be beautiful, and that open-source projects need more, not less, quality, that can be insightful.
Ack. |
Another week, another drama. https://github.com/actix/actix-web :
|
beside the needed patches from schinckel i add with 95413b7 a small How To into README, for #26
And 95413b7 enhanced the idea of: #22
And df6b5df adds a .gitignore