GitHub can be a little to good at pushing this. I've been taken to task for not having docs for my Open Source project which is on GitHub.
"But I do, they are on this website here and there is a link to them at the very top of the README!"
Didn't matter, I got told off for what was really "you don't have docs in the usual place on GitHub."
Very frustrating.
@patio11 I think it was made a comment in a blog about don't put Open Source on GitHub because you really build up GitHub's name not your own, which is an interesting point to discuss. EDIT: found it https://training.kalzumeus.com/newsletters/archive/do-not-en...
"This is one reason why, while I love OSS, I would suggest people not immediately throw their OSS on Github. That makes it very easy for developers to consume your code, but it does not make it easy for you to show the impact of that code to other people, particularly to non-technical stakeholders. To the extent that people's lives are meaningfully improved by your code, the credit (and observable citations) often goes to Github rather than going to you. If you're going to spend weeks or months of time writing meaningful OSS libraries, make a stand-alone web presence for them."
(For my project I'm using GitHub Git, Github issues, but everything else is on a website on a ___domain I control.)
So the real issue, it seems to me, is GitHub should be making it very clear, somehow, to users how to cite their sources? Most journals have a "suggested citation" blurb in every article's webpage.
Does git have built-in citation management?
That would be awesome, btw. That would arguably elevate git to the level of email: made by hackers for hackers, now universal to the fabric of modern life.
I think it's interesting how GitHub is trying to push open source contribution.
However, we shouldn't rely too much on GitHub for (open source) collaboration.
Git is decentral after all. Open source should remain too.
A surprising number of developers don't really understand that...which is partially a problem of how complex things generally are in development, and partially a result of how good Github has become.
Case in point: During the whole Julie Horvath controversy, a few anti-Github developers started a campaign to create awareness of the harmful effects of Github's culture (or something)...but they created their standalone site using Github Pages:
I pointed out, independent of how I felt about Horvath or Github, that not only does it send a terrible message to run a boycotting campaign on the service you want to boycott...it is completely unnecessary, thanks to how git actually works and the many other great build tools/stacks to do static web development in under 24 hours. However, I got reamed for being an asshole and "man-splaining" things.
But really, as useful as Github is, every dev should spend some time on thinking through what underlies Github, and how to get by without it...especially if you intend on protesting Github.
I don't think that was a boycotting campaign - it basically says "we recognise you might want/need to keep using GitHub, so if you want to make a positive contribution to better culture/whatever then here are ways to do so without changing your workflow". It was like airplane companies advertising carbon offsets.
Yeah, but the concept of "offset" implies that there is something essentially poisonous to counteract. You may have to continue doing some of these poisonous activities...but you're acknowledging that the consequences of them are negative, period.
"Offsets" may not be literally a boycott, but the message is the same. And if at all possible, the organizers of such should avoid creating more "poison" to "offset"...in this case, if you wanted to put your name as a pledge, you had to have a Github account, and you had to use Github's services...which, in the end, helps to perpetuate Github.
But the kicker is that using Github as a necessary evil is not necessary at all, thanks to the great work of open-source developers...
(and yes, the question of, what the hell does "offseting" Github's culture even mean is a whole separate mind-dislocation, but not worth debating in this thread)
I actually do this in many of my projects using BugsEverywhere [1]. Distributed bug-tracking is great when you're travelling ... or choose to be off-line.
It's very nice. You can use your fav editor and update pages, then push the changes back up and they appear in the wiki.
With a few plugins and some hacking, you can get vim to just browse the wiki too. (I'm currently working on getting my scripts for this into a state that is useful).
Unrelated - there are some plugins to use the github api to browse tickets in vim too.
(note not all of these workflows make sense as a primary way of using them, but they are still useful at times).
They make no mention of mailing lists or forums, which most sufficiently large open source projects have. It's often a good idea to sign up and get a feel for how things are done in a given commmunity, and for large changes, suggest them on the mailing list for discussion before opening a bug report or writing code.
Most of the advice about reading the docs is relevant. GitHub didn't invent those conventions, the whole README/CONTRIBUTING/LICENSE thing has been around for a long time. I remember being so impressed with Perl back in the mid 90's because it was so freakin simple to install, get up and running, and get help when you needed it.
After that, you should email the lead dev(s) and ask how you can contribute. Many projects have a mailing list and that's usually the best place to start.
Are there people out there that don't understand that software uses readmes and licenses, yet also are able to contribute code? I mean, people can program but not know how to contribute?
There are people who are just learning to code, who got the advice, find a simple open source project and help.
There are people who have only done early stage classes for CS degrees that want to practice in real coding but haven't been exposed to real world development.
There are people who have been coding forever but never paid attention to that stuff because they were always part of a team and didn't worry about it.
One extreme example: we had a person wander into the local hacker space on python user's group night. She had an English degree and had never done anything nearly as technical as coding. She knew that her library science degree would entail some coding and database knowledge and wanted to get up to speed prior to needing it for coursework. She understood the concept of community work and abstract stuff about open source, but not really anything on a practical level. Within the day she was helping one of the member's pet project by copy editing the readme and some of the tech docs. I'm certain she had no idea what a readme was when she got up that morning. (not exactly a code contribution, but definitely a project contribution). Within a couple of months she was able to get her first code submission to a project.
Ignorance and ability are not as correlated as people like to think they are.
>Ignorance and ability are not as correlated as people like to think they are.
thank god there are people who understand that. It's amazing to me the number of people who equate the two. Equally ridiculous is the tendency of programmers to spew advice such as "Read the fucking wiki (or documentation)". That really doesnt help newbs who are just barely figuring out the right way to Google things. The thing about being able to find some instructions on how to do X is that it's predicated on actually knowing that instructions are out there somewhere.
Tangential, but I think that one of the greatest gifts of experience and age (not that I'm old, I'm 33 - just not a kid anymore) is a lot of exposure to things I know nothing about. I now know just enough to be able to google lots of different things well, and better, have learned how to discover more things I know nothing about. It's a skill we (humanity) should spend more time developing in youngsters - being a specialist is useful and great, but being a specialist who knows of other specialties is even better, because then it becomes easier to link knowledge sets into awesome solutions.
"But I do, they are on this website here and there is a link to them at the very top of the README!"
Didn't matter, I got told off for what was really "you don't have docs in the usual place on GitHub."
Very frustrating.
@patio11 I think it was made a comment in a blog about don't put Open Source on GitHub because you really build up GitHub's name not your own, which is an interesting point to discuss. EDIT: found it https://training.kalzumeus.com/newsletters/archive/do-not-en...
"This is one reason why, while I love OSS, I would suggest people not immediately throw their OSS on Github. That makes it very easy for developers to consume your code, but it does not make it easy for you to show the impact of that code to other people, particularly to non-technical stakeholders. To the extent that people's lives are meaningfully improved by your code, the credit (and observable citations) often goes to Github rather than going to you. If you're going to spend weeks or months of time writing meaningful OSS libraries, make a stand-alone web presence for them."
(For my project I'm using GitHub Git, Github issues, but everything else is on a website on a ___domain I control.)