No one is arguing that having documentation is something undesirable, I believe. But a) given limited resources, more of A means less of B, and b) given that this is a non-commercial project based on willingness to contribute, any given individual is free to decide in regards of his/her contribution, whether A or B is to be preferred and in which proportion. (And obviously others can decide whether they are interested to use such a contribution or not.)
OK, point taken.
Then, as one who has volunteered, along with doing the testing, considerable time to keeping the project transparent to anybody who wants to get involved, I ask, in return, that at least a minimum effort goes into documenting the work to make a new build (or a feature within a build) possible. Without this, it prevents additional folks interested in getting involved from doing so when they don’t have a reference guide or roadmap of where to pick up on things they might want to work on.
To re-frame this: how likely would educovas, yourself, and others had gotten involved with the SL-PPC project, as y’all have, had there not been, at minimum, a wikipost collecting together all the work done prior to getting involved — helping to illustrate what had been done and what was still not yet tried? Without that documentation, how involved or likely would y’all have spring-boarded into the project?
All this work takes ridiculous amount of time. Unfortunately, we do not have a team of engineers able and willing to work on this full-time.
I know. Intimately. As do you.
And I also know it helps to be able to have the same notes amongst folks to be able to load-share/load-balance that work!
It would be better to have such a team. But it is not there
So having a perfect product with comprehensive documentation which gonna work out-of-the-box on every hardware is just not among feasible options.
As I said to z970 long ago, this isn’t a product, but an ongoing community project — a marathon, not a sprint.
As with other community projects, such as throughout the open-source community,
thorough documentation from contributors is foundational. I can’t really overstate this. And as one who’s heavily involved with macports, it’s something I know you‘re able to appreciate.
Throughout SL-PPC, I have volunteered to collect together new information as people come up with solutions and even breakthroughs (i.e., via the upkeep of the wikipost).
But in order to do that, one must have that information available in the first place.
If volunteers aren’t, you know,
volunteering that documentation of their donated work, then all the effort we undertake individually, voluntarily, ends up being isolated, siloed, and largely for naught.
Without that documentation, multiple volunteers may think, unintentionally, they’re working on something which hasn’t been worked on previously, only to find out hours of work later how, yes, it
had been worked on (but whose previous efforts were either poorly documented or not documented). This doesn’t provision a terribly efficient use of limited, invaluable volunteer resources.
I’ve regarded — and continue to regard — folks like you, ChrisCharman, educovas, Larsvonhier, pc597, swamprock, and many more to be an ad-hoc, informal, rolling SL-PPC team, as we’re able to give spare time in our lives toward it (hence the marathon or running relay metaphor).
And perhaps that’s also where we differ in our vantage around how we approach the transparency of what we contribute to this project, rather than to focus only on the end result, leaving everything preceding a kind of black box for everyone else. I’m trying to think about tomorrow as much as I’m thinking about right now.
I hope that resolves what I’m getting at here. Cheers.