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
Version control is almost ubiquitously used for source code, to the point it should hardly need mentioned; 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.
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'.
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**. 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.
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. 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.
This is just a rough start, but I wanted to post it here and get feedback before putting it on the wiki.
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. Take a look at this:
"to impart precept, oral instruction, and all other instruction to my own [kids], the [kids] of my teacher, and to indentured pupils who have taken the physician’s oath, but to nobody else."***
That last bit of 'teaching no one else' is a little tongue-and-cheek for the free software movement xD But, still, it has this aura of freedom of information that's interesting for ancients.
In fact most of the last two and the first two clauses, mutually apply to software. I'm the artistic type who would take the original oath and edit it to apply to software****.
* https://www.youtube.com/watch?v=tkm0TNFzIeg ** https://www.youtube.com/watch?v=yisaDxvBH9s&t=5m50s *** https://en.wikipedia.org/wiki/Hippocratic_Oath#Text_of_the_oath **** https://en.wikipedia.org/wiki/Intertextuality
On 6/5/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Wed, May 31, 2017 at 6:17 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
huh. hmmm, if it's ok with you i might run that by dr stallman, see what he thinks.
ok, so i spoke to dr stallman, it took me a while to get across the idea, and after clarifying it he said, *in effect*, "please could you write up some developer best practices as long as every GNU Project would automatically conform to them". he didn't exactly say that, so please do not quote me on it.
the starting point should be to take this "list of project *SERVICES* offered to the GNU project" https://www.gnu.org/software/devel.en.html
and turn it into a list of *GENERAL* project *RECOMMENDATIONS*, using the GNU server services as... like... the "Gold Standard".
the one thing that is missing from this list is a "Charter" - like how the Apache Software Foundation has a Charter. i am not entirely sure what to advise / do on that. over the past 20+ years i have witnessed many high-profile projects treat good people in some pretty horrible ways - not once and not on just the one project but many many times.
the Apache Software Foundation on the other hand, whilst they have had problems, their Charter has allowed them to (formally) keep things "civil", including being able to remove a project leader who clearly did not understand the harm he was causing to the project, through his actions.
also worthwhile considering is adding the recommendation for developers to take the "Hippocratic Oath for Software Engineers".
http://farmerandfarmer.org/medicine/printable.html
the nice thing about that oath is that it can just be added simply to make people aware of it... *without* actually requiring that they take it.
anyway i have started a page here in order to coordinate ideas and the actual proposal:
http://rhombus-tech.net/proposed_best_practices/
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk