I have a couple of vaguely popular repos on github (~100,000 downloads a month)
Generally speaking, (T-shirt farming aside), if you find a genuine typo, or small way to improve documentation, then that PR will be very much appreciated. README-typos are quite visible, yet easy for maintainers to overlook.
If you are new to GitHub, please do not be discouraged, and as with editing Wikipedia- be bold.
(In the large scheme of things, its really positive that so many people worked out how to make a PR, and were then motivated to do so- lets not shame them too hard. Although occasionally neccessary, we must be mindful about gatekeeping, especially with the young and inexperienced)
I have done one letter typo fixes to doc repos as a 3rd party and felt great about them. One of them was actually a typo in a command line that I found by going through their instructions step by step copying and pasting each line. I was seriously confused when it didn't work!
The point of the date it to tell people when the material was created. In some jurisdictions / situations, copyright expires N years after it was created, so that date tells people when copyright has expired.
Unfortunately, in many cases now, copyright is based on the year the author died, rather than the year the work was created, which means it is much harder to work out if something has entered the public domain.
Changing the date without changing the code significantly is arguably fraudulent.
doesn't moving the creation date forward in time make you vulnerable?
if you create some content in 2018 and I rip it off in 2019 and then you update your copyright to 2020, what's to stop me from saying I came up with it first?
That's partly why you have a span like "Copyright 2018-2020" - you are saying some of this material is older, some isn't. You need to keep copies of the older version with the older copyright to be clear which parts were invented when.
I want to like that idea. Unfortunately, I can counter with: When you (as an outsider) see two very similar projects, one claiming to be from 2018 the other from 2020, what will you look into/try out first?
Presumably, even if publishing date is relevant, it's only first publication that's relevant. No work should stay copyrighted forever just because it's constantly being republished.
I think they're referring to one example on Twitter (unfortunately, I can't find it again now) which was calling out a legitimate single-character typo fix. As someone who occasionally likes to report typos, I appreciate someone telling us they're appreciated :)
The pull request I have seen were changing "how to install" into "how to easily install" and such. They were not fixing typos or even making sentences better. They were just meaningless changes.
Not sure why the downvotes... the takeaway is it’s extremely easy for maintainers to tell a well intentioned docs change from the crap referenced in this article
Yes. It is easy to tell them apart. But some people are getting over 50 of these in a day, so even if it is easy to tell, it gets annoying and requires you to deal with spam.
That is the thing with spam in general - you can tell it from legitimate mail easily, but is it still annoying and requires you to deal with it.
That is why I still prefer old-style patch submissions via mailing lists - the bar is higher, so it usually weeds out exactly this kind of trash.
Of course, if a company started offering free t-shirts for mailing list submissions and some foolish (but well-meaning) youtuber would publish a tutorial on how to subscribe and post to a mailing list, I have no doubts that there would be a deluge regardless of this higher bar. :)
As a drive-by contributor to plenty of projects it raises the bar uncomfortably high though. A PR I can rebase and rework based on feedback that can be given right there on the line of code it pertains to. Easy as pie with GitLab or GitHub. Really bothersome with mailing-lists, and excruciatingly painful if they don't even use a modern DVCS like git.
(EDIT: I didn't mean to say that mailing lists are much better in every respect than GitHub/GitLab/etc, just that they don't deserve the hate they seem to get in every discussion about tools for collaborative development.)
As someone who has been contributing to Linux for a few years now, which uses mailing lists exclusively for all development (and not only do they use Git, they wrote it) I've found that mail-based workflows are in some ways better to GitHub/GitLab/etc:
1. You can review individual patches, you cannot do this in GitHub at all (commenting at the bottom of a commit doesn't count because it's not tied to the PR and the comment is lost to ether on force-push). GitHub also defaults to you reviewing the full diff and make reviewing individual commits kind of frustrating (you're just dropped into the commit history view rather than a proper review view).
2. All code reviews end up being line-based because the patch is the main body of the email. Design discussion happens as replies to the cover letter of the patch set, meaning you can easily tell which kind of discussion is happening. You can also directly comment on the git commit message, which the kernel community values a lot more than most projects.
3. You can far more easily be notified on patches sent to sections of the tree (though this is slightly tied to Linux's development workflow with subsystem maintainers). GitHub only lets you watch a repository and get the firehouse of events -- which is about as useful as subscribing to the main LKML and trying to keep up with the notifications.
As for difficulty, honestly the bar to entry to send a patch to a mailing list if you're using Git is just:
$ git send-email --to ... --cc ... origin/master
I would suggest doing "git format-patch" with --cover-letter and then checking the patch contents first, but you can do it one command for simple patches. Git was designed to make this mailing list approach work, so it shouldn't be surprising that it's actually pretty simple to use.
A code mirror and mailing list is a perfectly fine DVCS for the purposes of contributing code to an open-source project, and it doesn't lock a whole ecosystem into a monoculture walled garden.
> feedback that can be given right there on the line of code it pertains to
Done easily with a mailing list, and you can be sure that the comment won't just magically disappear because GitHub decided it was fixed even when it wasn't.
> excruciatingly painful if they don't even use a modern DVCS like git.
As far as local development is concerned, there's no reason you can't use all the git tools to manage your changes.
I don't want the walled garden — I don't care if its GitLab or GitHub or some other tool — as long as I can do stuff like rebase and squash easily and discuss the patch without having to subscribe to a mailing-list, set up inbox filters, prepare the patch for emailing, participate until the patch is in, then not forget to unsubscribe.
Comments about a patch are fleeting and should be gone after the patch lands — and should be treated as such. Any relevant comments will be in the source code.
GitLab (and several others) can be self-hosted for free; and the walled garden (GitHub?) is tolerable enough. And as long as you keep your software development practices sensible (centred around git, not GitHub), there hardly is a wall really.
> As far as local development is concerned, there's no reason you can't use all the git tools to manage your changes.
Certainly possible, but I didn't manage to get git-svn working the last time I wanted to contribute to a SVN repo. In the end I just created a local git repo in-place and generated the patch with git format-patch.
This is the outcome that would really suck - if people making their first contribution a legitimate doc improvement get their PRs caught up and marked as spam by maintainers who understandably mistake it as part of the spam.
I'm sure my first ever PR was adding an example to the docs for something, and if that had been closed with no response and labelled spam I doubt I'd have stayed around to contribute again.
One of the PR I made for hacktoberfest was fixing typo in a command in a doc. In the current case however, it seems people are not even trying to do something trivially useful.
On the other hand, I was told by boost project that my one line fix for a typo was "waste of maintainer time", so it seems to vary on per-project basis :)
It's so trivial to cherry-pick or rebase and merge such a commit if you understand enough of git to use it properly with branches and stuff. If the commit message is suitably worded it saves time too.
There are software projects out there, even highly used ones, that only use Github to mirror their SVN repository (or some other yesteryear source code system). For those maintainers these PRs do take up more time than they contribute though.
Limiting interactions is not the same as disabling pull requests wholesale (you can disable issues completely), they are temporary in nature (you can only disable them for 6 months at a time), and in addition I believe my comment was posted before they announced the new feature -- and this is a feature people have been requesting for a decade now.
Yeah, some maintainers are friendlier then others, and some seem to care more about their precious time then about encouraging people to make (legitimate) contributions unfortunately...
Generally speaking, (T-shirt farming aside), if you find a genuine typo, or small way to improve documentation, then that PR will be very much appreciated. README-typos are quite visible, yet easy for maintainers to overlook.
If you are new to GitHub, please do not be discouraged, and as with editing Wikipedia- be bold.
(In the large scheme of things, its really positive that so many people worked out how to make a PR, and were then motivated to do so- lets not shame them too hard. Although occasionally neccessary, we must be mindful about gatekeeping, especially with the young and inexperienced)