46
Show the site is safe and will not infect our computers
It's not "safe". GitHub allows anonymous users to upload anything they want including malware. You could get infected by downloading/executing code or visiting anything on the "github.io" domain where arbitrary javascript (and therefore 0-day browser exploits) might be found (github.com is safer ...
24
Make it clear that you want contributions.
Make it easy.
I would start by putting a friendly note in your project's ReadMe file.
This project is looking for contributors. If you have a feature you'd like to see implemented or a bug you'd liked fixed, the best and fastest way to make that happen is to implement it and submit it back upstream for ...
22
There is a giant problem with the logic behind this fuss. Storing the source code of malware is not strongly correlated with being infected with malware.
Consider http://www.metasploit.com/. It's a tool used by people protecting against intrusion -- and also by people looking to perform intrusion. Or any number of other resources used by people who study ...
21
Note that when you say it's "unnecessary", you mean unnecessary for you. That's not the right way to collaborate: if you want others to contribute then they should have the same conveniences as you (build files in the repo for their preferred build tools).
I think you can politely reject the patch, with a remark that you would accept a patch that contained ...
18
Don't merge, unless it meets your demands. All contributions are welcome, but only those that meet your standards are merged.
Whether that is test coverage, a style guide, or documentation, it shouldn't be merged until it's OK. You can choose to do it yourself when you're merging, or you can turn down the patch until it does.
As the maintainer, you are ...
17
The idea of the Cathedral and the Bazaar is a metaphor from the book named surprisingly 'The Cathedral and the Bazaar' from open-source avangelist Eric S. Raymond.
The metaphor describes two different development-models for projects (not necessarily open source).
The cathedral is a centralized effort. A defined group of developers (or even only a single ...
16
Reject it with a message.
Don't accept it; accepting it sends the signal that this is a good contribution and you want more of them. If that's not what you want, don't accept it.
What you should do is reject it with a note explaining why, for example:
Thanks for your contribution. Your patch was rejected because it simply replaced config files. Since I ...
15
To me, this question is very similar to how do I attract customers to my business? except instead of cash, you want contributions. Successful salespeople deeply understand their customers' needs and tailor their services to address those needs. It's a very powerful method: put yourself in your potential contributors' shoes, and ask what's stopping you. Many ...
13
Some guidelines that may be of use:
Always thank the submitter for their patch (unless you really don't want them to submit any patches anymore, which could be possible)
Establish guidelines for patches, and make sure contributors can easily find them. If you don't want IDE config changes, put it in your contributing.md (or equivalent).
Let submitters know ...
11
I would believe that testing the project is the responsibility of all collaborators. It should fall under the hands of the contributor, as well as the maintainer. For example, a contributor should never let this go through (code in Python):
import os
os.system("rm -rf /") # Mua ha ha
Contributors should be wary of what they submit, but they make mistakes. ...
11
This is part of the purpose of version control systems, like git.
When someone makes a new feature, or changes any code at all in fact, they have to commit it to the project. It's a bit like editing here on Stack Exchange: when you edit your post, an item is created in the post's history showing the changes.
If someone sabotages your post (or in this case, ...
11
Congratulations! The problem you face is a common one for a popular open source project.
IMHO, beginners should above all learn to communicate!
So you could explain in your CONTRIBUTING file what a simple process would be when someone wants to work on a ticket.
When there are multiple aspiring contributors I make sure that each is aware that others may ...
11
Open-source maintenance is often volunteer work. As a volunteer, you do not owe your time to anyone and can always say “no”. So it is absolutely legitimate to close any issue that is not comprehensible, ideally with a polite message in simple English that has a good chance of surviving machine translation. I would consider such a response to be more polite ...
10
In corporate software development, all developers are, typically, using the same IDE running on the same version of the same operating system
This is a misconception. Example:
I run Eclipse Luna with openjdk-1.7 on Ubuntu 15.04, my colleague runs Eclipse Kepler with oracle jdk 1.7 (previously 1.6) on Windows.
Still we got our builds working.
The goal is ...
10
I'm a solo programmer, not any firm. But suppose if I were to form a small firm tomorrow and decided to write a security guideline regarding what to allow/disallow from github, it will be implemented something like this:
Only allow github.com domain and not github.io. Reason is that the latter is a web-hosting playground where any random developer can place ...
9
This is a really broad subject so I'll answer at a very high level and not touch specifics unless they are relevant for OSS.
"Works for me"
This is really the crux of the problem; you have build environments that are different in a way that affects software behaviour. The industry at large has been tackling this for decades, and a number of best practices ...
9
I'm playing with the wording in your question a little bit, but don't change it up because it will likely make this entire answer invalid.
Anyways, let's break down the question by well... question:
What happens if the main contributors of an open source project die?
Well, the project will die down. Likely, a lot. The key part here is that the core part ...
9
Start by writing down a list of current issues and make sure it's easily accessible. Other contributors will then have a clear objective: they can fix issues!
Continue by writing down a list of anything you would like to change long-term, in small steps. This allows new people to see what the initial thought behind the project was, and they might want to ...
9
Sadly, there is little you can do. I believe you can argue that you accepted the code in good faith, and avoid the worst. Try to collect and organize any evidence of the affair (emails, commit identifiers, ...). Keep a copy of the current version control system contents around.
To replace the tainted code, you can see if you can set different objectives (...
8
Discuss, discuss, discuss
This is absolutely essential. You can't solve personal problems digitally - so when I say discuss, I mean call a meeting. You need to sort out some things with him:
Project focus
If everyone has a different idea of where the project's going, it's obviously not going to work. This is the root of the problem. Discuss with him what ...
7
I can think of a few points
Documentation is key - Not just usage documentation, but also development documentation! How do I build your project? How do I run tests? How do the internal APIs work? Github has the wiki feature for that, although you can just create a directory with a bunch of .md files.
Make your directory structure predictable - Look at how ...
7
You can recover that specific link via the way back machine:
http://web.archive.org/web/20150507060802/http://jira.codehaus.org/browse/MASPECTJ-131
codehaus says from their termination page that you can redirect your projects:
If you would like your projects links redirected then please see our redirector repository - create a sane squashed pull ...
7
First and foremost, testing the contribution is responsibility of the contributor himself, before submitting a patch, to see if it breaks something or otherwise causes problems when combined with the rest of the codebase. This is true for every programing job, not just open source, testing their own changes is the developer's responsibility.
That said, once ...
7
Just do it!
Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.
If the project is using Git, make sure you adhere to best practices with regards to branching and ...
6
Answer to your first question, getting involved with an open source software is as easy as looking at the About section of your favorite software.
There are loads and loads of open source software around and as a FOSS newbie, it's easy to get confused as to which one to pick and start working with. I'd suggest a software that you really care about and ...
6
If you remove those projects: fine, that's your decision.
If you don't remove them: make sure you mark them in the sense that you add a visible note saying "THIS PROJECT IS NO LONGER SUPPORTED", so that a visitor who stumbles upon your code knows that he's spending time on a dead project when he decides to use your code (he can have very good reasons to do ...
6
Generally speaking, finding contributors is very difficult. Benjamin Mako Hill described in a talk at Libreplanet that the median number of contributors to Free Software projects is 1.
That being said, it is a good idea to ease people into the process. Make it easy for users to file good bug reports, maybe by adding a reporting tool to your software. ...
6
Reject the patch if it doesn't have a tangible benefit - does it help compilation on other platforms, etc? If not, if you have no reason to accept it, you have no reason to accept it. If it's some compilation helper that could work alongside your method then that adds value, otherwise it doesn't move things forward (and using it could hold you up, at least ...
6
Reject the change and add some contribution guidelines
You should explain that the contribution whilst not without its own technical merit isn't strictly a contribution that adds anything to the project goals. Explain that this is what forks are great for and encourage the contributor to maintain their own fork. Thank them for their time and add some ...
Only top voted, non community-wiki answers of a minimum length are eligible
