Well, I didn't downvote you, but you're essentially asking for free work. If you want contributions, you need to contribute yourself first, usually by writing some code (or paying someone to write if you cannot) and publishing it.
A basic version that doesn't work well yet is OK, an empty repo isn't.
The repo isn't technically empty. :) I put a bit of work into describing the requirements of the proposed software and making suggestions how to proceed.
Basically I was volunteering to tend a garden, not just suggesting that someone plant one.
I've just added `remover.go`
package main
import "fmt"
func main() {
fmt.Println("Limited functionality, WIP.")
//Display introduction message and prompt user if they'd like to continue.
//Determine if current process has permissions to make system changes
//IF yes continue
//IF no initiate appropriate OS call to prompt the user to elevate
// OR advise user how to quit and start over with perms.
//TODO figure out if we're on Mac or Windows
//IF Windows...
// Look for process CCNet.exe
//Criteria: it's insufficient to match the name. Checksum? Publisher name? Install path?
//If found
//var installLocation string = ?? //record the install location.
//terminate process
// Look in these directories for installation
//C:\Program Files\WinSS\Book
//installLocation //defined above
//IF found
//Delete
//IF not found
//Prompt user to offer a suggestion
// Look in this directory for key log files
//C:\Windows\WinCCNet
//IF found
//Prompt for delete
//If not found
//Prompt user to offer a suggestion
// Remove the Add/remove programs entry
// Remove auto-start keys //TODO Where are they?
//IF Mac...
// ???
}
If you want my personal opinion, offering to work isn't enough. You need to have stuff done already. How am I to know that I'm not being suckered into working for you for free? I'd say that to volunteer 10m, I'd need to see 10h of work already done.
Secondly, a small project like this doesn't need a full-time gardener/manager, especially for an objective goal like this (unlike, say, a videogame). If and when a project reaches that need, someone who has contributed important code is preferred. Code talks.
So, in this case, you already know the requirements, right? Does that ease the blow of being told what to do? I mean, also I assure you that I'm not trying to tell you what to do. I presume that more or less the same items would appear on the TODO list if you told me what to do.
I can and will give up on this whole idea if it's truly a bad idea.
But, lets look at some alternative timelines here. Suppose that I'd immediately hunkered down and started writing an uninstaller in isolation. Note: this is not something I'd finish today. Thus: by the time I had a working or semi-working uninstaller, the world would have moved on.
By starting the work in public, I hoped to avoid that eventuality not just for myself but also for anyone else who might otherwise have walked that path. (Experts who could finish the software quickly don't need the suggestion, of course.)
And, by starting the work in public, I hoped to reduce the cost-of-entry for others. I mean, I don't know about you, but I'd rather start with a couple of kb of skeleton than an empty repo.
I likely can make one in a few hours, if I made it I'd put it on my blog. What is your contribution to the project? Why do you even need to be involved?
Think why would anyone be motivated to contribute to your repository, as opposed to creating a new one from scratch under one's own username.
Imagine you got a first pull-request, with a Go app. Then another, with a bunch of working Python scripts. Then yet another, providing a complete Python app packaged on PyPI but somewhat broken. What will you do? It doesn't matter: x-1 of x people have just wasted their time writing code that will end up under your GitHub username anyway.
Yes, it has to do with reputation management, too. You'd have a project under your GitHub name written completely by other people. The way it works currently, people will tend to see it as your project. You'll be free to claim it in your portfolios and resumes. Meanwhile, creating a GitHub repository isn't a hard task, and your README contents is basically what normally happens in one's head as one designs and writes the software.
In addition, and that's what may have actually caused the downvotes IMO, there's something not enjoyable about the idea of stumbling across a bunch of orders issued by a random person in writing to undefined audience, which you unexpectedly find yourself part of, by virtue of reading those orders. Your requirements, without any code, sure looked like such orders though.
It wouldn't be a problem be there a big name or much publicity associated with your project (and the resulting network effect), but without that there's no challenge and no meaningful payoff.
* * *
Things would be different if your repo had a well-thought-out skeleton consisting of some (even if completely no-op) units and a (failing but thorough) test suite, tied up to Travis CI and what not.
That would increase motivation as it would eliminate quite a bit of actual friction associated with starting a new project.
Arguably one of the hardest parts would be already done—us lazy programmers will be able to look at the units, the tests, and figure out how to make it work. No need to even clone, just edit some files via GitHub web interface.
> It wouldn't be a problem be there a big name or much publicity associated with that
My end goal is for my local police department to pass this uninstaller out to citizens, in a similar manner to how they passed out the installer. That will never happen without the support of a big name. I'm hoping the EFF will take an interest (I've already put my name on their volunteer list some time ago).
> humans don't enjoy the idea of being given orders from [random] people. Your requirements sure looked that way, though.
...I'm sorry. :( I'll look back over the README for use of the imperative voice. ...Honestly, I've heard this feedback once or twice before AFK and I wasn't sure how to change then, either.
> When I first imagined this project, I didn't picture it taking all day, from start to finish. An uninstaller doesn't do much.
That's part of the problem: drilling the problem down to atomic subtasks, which is needed to estimate, is the actual hard part. With that part done it would take little effort to complete the project, and contributors for further improvement would be easy to find.
That's better, but “Forked from…” small print doesn't escape anyone's attention, and in any case this issue goes beyond GitHub service. You'd be a ‘founder’ of something without having done much for it (keep in mind I wrote my comment before you added remover.go, and also I might be wrong about this whole point too).
Sorry for calling you a random person, I was just trying to explain what I felt when I opened the repo and took a look at it.
> Things would be different if your repo had a well-thought-out skeleton consisting of some (even if completely no-op) units and a (failing but thorough) test suite, tied up to Travis CI and what not.
Absolutely.
Here's the thing.. I can do that in Java, but not Go. I don't know how to do it in Go. Maybe that's really where I went wrong on this. (And wrong I went indeed! The downvote rate increased when I attempted to defend the idea.)
You see what I did there? There isn't any code. :) But that can change very quickly via pull requests, right?
Any recommendations? Is this the right way to solicit volunteers for a little one-off project?
[edit: switched from personal repo to organization repo per feedback.]