Roberthh wrote:I have the impression that Paul & Damien do already a lot to document the product and it's changes.
The trick is not to do a lot, but to do little and still cover the important parts.
Roberthh wrote:Many of the issues raise here could be avoided if people look into the documents.
I don't think anybody really had this kind of commitment to a project that doesn't care much for them. It's drinking from a firehose. Unless you are paid to do that for 8h a day, there is no way. I tried it. I lasted about two weeks, and it prevented me from doing pretty much anything else.
Roberthh wrote:I doubt that there is a kind of long run plan about which changes to implement and it's possible inconsistencies over the next n versions. And some of the the changes people complain about were cause by improvements in error handling and language conformance of MicroPython.
Yes, this is a big part of the whole problem. There is no plan. There is even no policy. It's all up to the last-minute whims of the developers. Like that, MicroPython will never be stable enough to use it without making your own fork and hiring people to maintain it.
Roberthh wrote:So maybe it's better make use of the 1000 eyes of the people, and let us all report on inconsistencies being found at a special section of this forum, allowing all of us to look at a this specific place, if code after a version change has a hiccup.
That's not possible. This kind of task can't be split into 1000 eyes, each doing a small part, because it's about spotting missing things, not finding something that is there. So you really need one person that reads *everything* and remembers it and can see the problems. Or, alternatively, you can introduce a policy for the developers to document what they change when they change it (or even better, when they plan to change it) in a way that is accessible for the users. And copy-pasting a list of commit messages into the changelog is not going to do that.