"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.
That's a very valid point. However I think the point of a standards organization should be to spread information about their standards that aren't widely or commonly known and it highly useful. Ultimately there will be some very new people looking for information, and for them knowing about the usefulness of version control would be important. Again, though, if only mundane things like that were taken on as a core tenets, I don't think anyone would take the organization seriously.
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.
I don't think there is much wrong the way github is designed, so much as it's economic model for sustaining itself. It requires closed source software development to survive. That's naughty.
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.
We really don't want to throw around that label, it'll be controversial if we do. The overall point I was try to make in that clause is, 'everyone thinks to collaborate on source, but no one thinks to collaborate on assets'.
I don't think many realize it's possible for 100+ people to collaborate on a single drawing using version control and effective curation. It'd be absurd, but it'd be possible. As it stands, most assets are designed entirely by a single person, because people don't realize the collaboration tools and methodologies out there.
"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.
Hmm.. *searches 'Agile development methodology'* I agree. I always hated those cause they felt like a tight 'inside of the inside box' structure. What I'm suggesting here is Definitely a collaborative methodology and -I think- a pretty abstract and general one.
Essentially the point is, in a large open development, odds are there will be people more senior and more novice to you. To develop the most difficult code 'for you' possible, we prioritize personal development over project development. I think that's a pretty solid general rule. If the code is really sincerely important, someone will clean up your mistakes and use your successes.
Yes, I the principle is of focusing on the individual, but there's nothing more important to remind a collective to do.
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.
For one, I think that's problematic. There are some projects to advance humanity stuck in closed-development, sometimes for honorable not-profit-motivations. Take radar development for example. Or, AI development. The last one is a hot-button topic, but I think AI development has to be relegated to those careful to avoid AI hating us.
For two, Some projects have a goal besides open source or profit. I really like Star Citizen*. They show us EVERYTHING, except their source. Obviously they can't because what they are trying to do, Requires modding closed source software. It's very open, even if it's very closed. If an organization like that wants to contribute to the development of some libre software they are borrowing, we should recognize them. Maybe if we buildup a strong rapport with them, they'll release their game into the public domain one day just to say 'thankz, for all the lulz'.
* https://robertsspaceindustries.com/about-the-game
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision not to use kicad, there will be many incidences where open projects need to decide between modding-up open software or using proprietary software. Occasionally, the former is just not practical.
A standards organization, would do best to make sure they weighed both possibilities realistically and didn't just assume one or the other was more practical.
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?
Both. Most languages today are pretty esoteric, even today. And, the problem isn't so much with the docs, as these languages were designed for people that already new another language equally esoteric, etc.
I would think Lisp's resurgence (as well as developing Guile) is a demonstration of GNU trying to break away from that paradigm.
[blah blah blah about making programming easier]
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.
I recognize that intuitive isn't always concise, but often it is. I only mean concise when it means intuitive. If a projects roadmap demands a large code base that is highly-esoteric and unintuitive, then that exhibits fault in the underlying language.
I'm not suggesting any project change to prioritize this. To the contrary, I think I was quite clear: a project should only dedicate 'extra' resources to this type of endeavor.
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.
No one will want to advice from an organization that bible thumps the same points, much less financially support them in exchange for doing so. I think it is important to develop universally acceptable principles (i.e. things people find interesting to hear, but not necessarily want to hear) which are useful.
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".
Eh, 0-to-1. Redundancy is nice, but can be confusing. I think it would probably more effective to just let any libre hosting service which has criteria A call themselves savanna, but I don't think were a person stores their code should be a huge point of tension.
Ultimately, in a 0-to-1 paradigm, we are trying to develop closer to perfection, rather than closer to more competitive. Having multiple types of libre hosting services is like having multiple https://en.wikipedia.org/wiki/WP:POVFORK 'es.