--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jun 5, 2017 at 10:47 PM, John Luke Gibson eaterjolly@gmail.com wrote:
Alrightie~!
Foremost, since "existing" free software and cultural works aren't likely to be sold, I think a libre software standards organization wouldn't certify individual works or pieces of code, so much as projects as a whole including roles performed by non-developers
indeed.
Version control is almost ubiquitously used for source code, to the point it should hardly need mentioned;
absolutely dead-wrong. it needs *absolutely* to be clearly defined. the practice of saying "well everyone does it so we don't need to take special note of it" is how, historically, utterly valuable knowledge has been lost through the ages.
a good example is all the folk tunes of medieval times: *nobody knows them any more* because quotes everybody knew them quotes so NOBODY WROTE THEM DOWN.
so no, john: it *is* critical that everything that's ubiquitous and quotes obvious quotes be formally documented.
then, not least, you will discover that actually, everybody uses github "by default".... which, when you read (and take) the software engineer's hippocratic oath you find that it's very hard to honour that oath and use github at the same time.
however very rarely are non-source project files, such as .blend files, collaboratively designed this way. I don't think people are unwilling to use version control in this way, rather they just don't think of it since most artists aren't developers and art has been digitally designed for much longer than version control systems have been easy to use. So I think uploading files to repository and saving changes as commits, would be a good 'non-developer' "best practice" to apply to a software certification standard.
if they're "developing" then by definition they *are* developers, whether they think of themselves that way or not. in the hippocratic oath (both the original and the engineering version i found) it mentions that both practices combine art *and* science.
Anyways, developer 'best practices'. Having idle hands study and document code, particularly esoteric parts or parts they, the contributors, are unfamiliar with (so they can learn it*). Generally, the instinct we are taught from criticisms of our artwork, is that 'if we can't do something well, it's best not to do it at all', however with our version control systems generally the opposite is much more likely true, leaving room also for the hopefully soon to be colloquial: "if a task seems too easy, it is best leave it for someone else more novice; if a task seems too difficult, it is best to do it sloppily, so someone else won't have to do it start from nothing". So I think doing the best we possibly can do to develop the worst code and worst documentation we possibly can, (xD) is another good developer 'best practice'.
ok... there are two different definitions of "developer best practices". the above goes into detail on how an individual developer should best carry out the development process; the document that i would like to see written is one which helps people (covering both users *and* developers) to work as TEAMS. what INFRASTRUCTURE and general mind-set will help people to work together.
not "as a developer we must apply Agile or other Methodology". that's not appropriate: we have no proof that Agile or other "Methodology" will be more effective than any other, and i don't believe it to be appropriate for us to even research that.
Most of us know it's not uncommon for very large projects to receive access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups, so this is not a concern.
Likewise libre software is often perceived as insufficient as-is, however proprietary software can be close enough that it is more practical. In these cases, we need to respect reality, however also ensure all is carefully weighed. The biggest pitfall is looking at all the forks, addons, and extensions, then also looking at what you would like to do that one can't with proprietary software out of the box. Whilest being careful not to berate preferences, looking at how modifiable the base program is and what it could accomplish rather than what it can accomplish, is an important thing to make sure both project's developer's and non-developer's occasionally remember to do. So, considering what we could do more proportionally with what we can do, is an important developer and non-developer 'best practice', especially since as least occasionally they'll make one of their could-do'es someone else's can-do.
i don't understand where you're going with this. what is the main point?
Another practice that kindof ties in with the other one, and an often unsung aim of the GNU project as a whole, is make programming easier.
to make *programming* easier or to make *collaboration* easier?
Occasionally, a project will have extra resources or volunteers/contributors than their described roadmap warrants. Not always is this obvious from the beginning when it does happen. In fact, usually it isn't till the end that it becomes apparent. The ideal would be say 'even if proprietary software is more practical, use/extend free software for the benefit of everyone when you have the resource', but the reality is very rarely will you know you have the resources until it's far too late. Instead, a good programming practice might be to use the extra resources to modify the language itself or some api to make the code smaller. We all should know line counting is a trap, but we should also know we are more likely to read a pamphlet than a book. So, it should be a good developer 'best practice' should be to use extra resources at the end to make your code intuitive and concise, and to fork others so hopefully adaptations to libraries and compilers that make your code more concise and intuitive get upstream.
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
This is just a rough start, but I wanted to post it here and get feedback before putting it on the wiki.
wrong focus / direction, john.
the first step *really is* to quite literally copy - verbatim - the gnu devel.html page and "generify" it.
where it says "we recommend savannah" put instead "we recommend the use of a Libre Hosting Service which has a minimum criteria of an A, as defined by the FSF's Hosting Criteria".
where it says "we recommend mailing lists on gnu.org" put instead "we recommend the use of software libre hosted mailing lists". a later revision should go into further detail as to *why* "announce", "users", "dev" etc. is recommended.
etc. etc.
this is a completely different focus from advising people on *coding methodologies*.
I really like the analogy of medicine to software development, particularly the use of the Hippocratic Oath as a point of reference. I was looking at the 'original' oath, and there is an interesting intersection with the morals of free software.
indeed there is.... but that is simply not understood by the majority of people associated with free software. you can usually tell who they are because they use the words "open" and "source".
which is why i feel it should be part of the recommendations. again: it is one of those things which is never really discussed because those people who *do* understand it just... follow it (without talking about it) and that means that those people who *don't* understand get really *really* confused and misled.
l.