39

Personally, I've used a self-star as a tiebreaker to call out better projects. If two of my projects both have N stars, and I think one is clearly better than the other, I'll star it so that it ranks over the other one in my profile page. This is especially important if I have many zero-star repositories, because some of them may not appear on my profile ...


28

There are a number of options, and I've had to do this in the past for real. But beware - you could end up a new committer for the project. The most straightforward is to pull the project owner's email address from the git log and send them a polite email asking about the status of the project. In my case, I found there was a mailing list where the project ...


19

If there are "many long-open issues and pull requests, and nothing is changing" then you don't need to ask - it's just assume the project is not being maintained. Open issues aren't an indicator, maybe the project maintainers don't think they're as important as the person who opened the issue. Especially with popular projects, the issue tracker will often ...


17

You should (github) fork when: You intend on submitting pull requests back upstream. The maintainer doesn't like your new feature set, so you decide to add them anyway, and maintain the fork in parallel, routinely merging in changes from upstream as an alternative to the main branch. (Note that you may be required to change the name due to trademark ...


16

Note that when the starring feature was introduced on GitHub in August 2012, they converted all of your watches to stars during the initial migration. As you are automatically added to watchers to your own repository, this meant any repository you've created prior to this change would appear as starred for you. For me this migration choice means that it's ...


12

Forking and starting your own repo and submitting a PR to the current repo are not mutually exclusive. You could do both and decide which branch to keep working on based on the action or inaction of those who have been involved in the past. I think public communication would be preferable. Since there has been no activity in 2-3 years, your public ...


10

Update 2016-03-11: What do you know, GitHub have just added a feature to add reactions to issues (and PRs and comments). Among the reactions available is a +1. This will probably be the way to go. Old answer As of writing, this is not possible. There's a feature request dating back to 2013 for this. There's even an open letter listing this issue. Instead,...


7

It doesn't violate normal free software licences, and it's not unheard of. The email client alpine, released under Apache v2, on first invocation (and, if memory serves, after major upgrades) displays this message: SPECIAL REQUEST: This software was originally created and maintained as a public service by the University of Washington until 2009; ...


6

The harsh-reality answer: You are the project maintainer. Contributors may not like it, but technically, you can reject PRs for any prosaic reason. "My ability to open the project is a requirement" seems like a reasonable requirement to me, but I'd rephrase it so it doesn't focus on you, but on all users and contributors - "EnumStringValues supports VS2013, ...


6

Normally, help is very welcome. But every project has its own culture. Sometimes it's spelled out explicitly as a “Contributing” guide, sometimes it's implicit and you'd have to learn by lurking. It is best not too invest too much effort at once. One reasonably-sized pull request at a time. This helps you to become familiar with the conventions of the ...


6

Forking implies a few things which may answer your question. First, the original author - by using a free/libre license - authorized you to fork, for whatever reason. You cannot "steal" something what has been explicitly offered for you to take. When forking, you keep the (preferably full) list of the original authors, giving them their credit. Since you ...


6

When the original owner has abandoned their project, they might be quite glad about someone wanting to take over. You definitely have nothing to lose by trying to contact them. Taking over the name without their consent would be inappropriate.


6

If your PRs aren't being accepted, the best course of action is to published a scoped version of the package. You can do this even before you think that your PR is being ignored. If you make substantial changes, and after a long while your PRs are still being ignored, then you could consider publishing it with a different name.


5

Don't be too bothered by etiquette here if it stands in the way of your project. There are roughly three scenarios you can follow, each with its pros and cons. The straight GitHub Fork. This gives you Easy pull requests, with lots of tooling around it. Stats gathered by GitHub, able to track your contributions in the tree graph A note on the project that ...


5

I don't know if there are any rules around this but I think it is a matter of choice from the user. In SE you can star your own post, but you can't upvote your own post (question or answer). However, in Reddit a post is upvoted by default by the user. Now in my projects, I starred only those that I think worth it. Something like "Hey traveler! Look ...


5

So you want to distribute parts from an article which has no license. If the parts are eligible for copyright protection : You are not allowed to distribute these parts at all. If the parts are not eligible for copyright protection (or something like "fair use" etc. applies): You are allowed to distribute these parts. You don’t have to attribute (...


5

First rule, do not fork. Forking is only used on GitHub to contribute changes back (which shouldn't be the case for you). You can, at your preference, decide to clone the repo and keep the history, which won't be a problem if your project becomes big as the original repo only has a short history of 92 commits. Or choose to just take the code and create a ...


5

Putting together a PR may take time, especially if this is the first time someone contributes to this project (or to open source at all, for that matter!). I'd give a grace period of at least a week or two, but after that, you should reach out proactively. Not only is it not rude, but if you phrase your communication properly it will come off as encouraging, ...


4

In order for your release to remain stable, you're going to need to fork that unmerged branch yourself. Otherwise, that branch may disappear, rendering your package unusable. As you mentioned in the comments, it would be best if you kept an eye on that branch so you can update your documentation and kill your fork if & when it gets mainlined.


4

is it acceptable to change the implementation language via pull request? Everything is "acceptable" for you to propose... but not everything may be accepted. If you were to submit a PR to one of my project that support Python2 and 3 and that your PR makes it support Python 3 only, I will very unlikely merge your PR unless I am ready to abandon Python 2 ...


4

I really would like to continue helping this project. Is there any general rule of etiquette on GitHub or open source projects in general that I don't see? This is my first major project I helped with and I spent a large number of my free time working on it recently so am slightly angry to be told this. In general: they are the owners of the project, not ...


4

Yes, it is reasonable, but it will be most reasonable if you create yourself the patches for the docs / wiki. So, don't just go around suggesting things to be improved. Improve them on your own, and sent ready mergeable patches! Of course, if you can propose or provide code changes to avoid those issues / difficulties in the library, that's even better! ...


4

Well, there is no rule for etiquette, but there is common sense. Most internet communities have a form of etiquette, many explicitly did write it down. And you will find common points: don't hate, don't insult, don't threaten, don't troll. Be nice to others. This is no official common code, but it shows fast that if you actually tolerate bad behaviour your ...


4

If your project is also on Github, create an issue on your project detailing your relationship to that dependency. Link to the dependency's issue that you're blocked on. Github recognises such inter-issue links and acknowledges them inline with comments on the dependency's issue in question. Example from ariya/phantomjs#10196, which many other projects ...


3

As a maintainer, I have to disagree with the answers telling you to give a ":+1:" on the issue. We use that as a signal that the maintainers have "blessed" a feature, i.e, we're likely to accept a pull request that implements/fixes the issue. As was pointed out, a bunch of thumbs ups raises the noise level and makes it difficult to find relevant info when ...


3

Depending on the programming language you are using you can creatge a mergerequest with a disabled/ignored unittest. This avoid having failing-unit-tests in the code branch which can be easyly reenabled when fixing the issue.


3

To resolve this problem you can fork the version that includes a feature that you need and resolve the check problem. After that you can submit the PR with your changes. An example: There exist a project called A by some developer add the feature to fly over the world inside the fork of project is called A1. This fork A1 does need to define some additional ...


2

If it's your project, you should make sure it actually works. Whilst you can't check that some proposed change works (and doesn't introduce anything malicious), you should only pull it if you know the author well already and trust them. That's the only thing I'd consider “ethically mandatory” here. If the PR is a risk factor, don't pull it. That ...


2

To add to @amon's answer - another consideration may be the timing. Some projects use strict development cycles (or sprints). For example, a certain development sprint may concentrate only on improvements to feature X and during that sprint changes to Y are rejected. Another example could be that a project is nearing a release and is now focusing on ...


Only top voted, non community-wiki answers of a minimum length are eligible