Maybe Micropython needs more people?
Maybe Micropython needs more people?
It seems with the recent delay of release 1.14 and >300 pull requests and >800 open issues, doesn't Micropython really need more people developing this project?
Was this discussed yet? I wonder what Damien's thoughts are on this, is it a money issue, do people not have the time or not the skill to contribute effectively? How do people contribute effectively? Is the main issue advertisment and there any plan for public PR? Should people contribute to Circuit Python (because some say that's the future) or to Micropython, since it's the base?
Maybe wrong branch to post, but it kind of felt appropriate for 'development of micropython' as in growth of the whole project
Was this discussed yet? I wonder what Damien's thoughts are on this, is it a money issue, do people not have the time or not the skill to contribute effectively? How do people contribute effectively? Is the main issue advertisment and there any plan for public PR? Should people contribute to Circuit Python (because some say that's the future) or to Micropython, since it's the base?
Maybe wrong branch to post, but it kind of felt appropriate for 'development of micropython' as in growth of the whole project
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Maybe Micropython needs more people?
I'm loath to comment in detail but I think that @Damien's laudable focus on code quality limits the bandwidth for user submissions.
I do think that the difference between MicroPython and CircuitPython needs clarification as their focus is quite different. CircuitPython aims, above all, to be beginner friendly. As such it omits numerous performance-focussed features of MicroPython such as interrupts and (currently) asynchronous programming. To get the most from MicroPython requires some investment in time. In my opinion this is well worthwhile. Many of my projects would have been impossible in CircuitPython.
There is no question that MicroPython is well ahead in crucial features, not least an entirely new and much improved uasyncio library. Given that asynchronous coding is at the heart of most serious firmware applications, this is a big deal. IMO, of course
I do think that the difference between MicroPython and CircuitPython needs clarification as their focus is quite different. CircuitPython aims, above all, to be beginner friendly. As such it omits numerous performance-focussed features of MicroPython such as interrupts and (currently) asynchronous programming. To get the most from MicroPython requires some investment in time. In my opinion this is well worthwhile. Many of my projects would have been impossible in CircuitPython.
There is no question that MicroPython is well ahead in crucial features, not least an entirely new and much improved uasyncio library. Given that asynchronous coding is at the heart of most serious firmware applications, this is a big deal. IMO, of course
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Maybe Micropython needs more people?
Thanks for the answer even though not detailed! In other words the 'inventor' of micropython is at his limit to quality check everything and that creates a bottleneck. Is there anything that fellow community members / readers / enthusiatsts can do to help with this sort-of bottleneck?
Re: Maybe Micropython needs more people?
There are a few people working on Micropython. Especially contributtion to ports are in control other people too than Damien. But it is also true that Damien controls the core software of MicroPython. And that is good. It ensures consistent quality. The feedback time is reasonable, the quality of feedback excellent.
If you look at other branches of MicroPython, like the Pycom branch, you see the downside of several people working on the product. No one seems to have full view and understanding of the firmware. There seems no process for reviwing and eventually integrating PRs. Occurrences of bug regressions, ... All caused by communication problems. Adafruits seems to be a little bit better organized, but also there it seems to be a very small group of people controlling it, like 2-3.
If you look at other branches of MicroPython, like the Pycom branch, you see the downside of several people working on the product. No one seems to have full view and understanding of the firmware. There seems no process for reviwing and eventually integrating PRs. Occurrences of bug regressions, ... All caused by communication problems. Adafruits seems to be a little bit better organized, but also there it seems to be a very small group of people controlling it, like 2-3.
Re: Maybe Micropython needs more people?
Helping out on github can do quite lot. For instance there are always issues being raised which aren't actual issues and/or belong on the forum; pointing that out and helping people means those issues can get closed without any interaction from maintainer(s) required. Likewise: reviewing PRs, within your capabilities of course. Just simple things as checking spelling/grammar get the PR in a better shape, i.e. less work. Another simple one is double-checking against contributing.md rules for code style/commit message format, people often forget those so if someone points that out it's again less time/effort needed from others. I'm just mentioning these because they don't even require one to know C or the MicroPython internals. Of course if you do, review code as well.
Re: Maybe Micropython needs more people?
Documentation is usually my top suggestion.
Especially documentation that facilitates high quality PRs, or helping people get started with their first PR.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Maybe Micropython needs more people?
On which topic, whatever became of the Season of Docs? I thought this provided 3 months full time effort from a professional technical author.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Micropython Internals doc
Wow. There's some serious bedtime reading there! From a quick look, highly recommended.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Maybe Micropython needs more people?
So sad it will be outdated even before it merges.