Repository navigation
Kill tip4commit #157
Description
Activity
+1
This is more of a philosophical discussion, per @bill-auger 's note in #156 it would be preferable to move this to a forum on the tip4commit site. Users there are not necessarily github contributors.
If consensus is developed there to shut down the site in response to negative feedback, I think we can open a ticket on how to wind down the operation here.
There is no need to kill the project, all you need to do - seriously - is to make it opt-in only. The only thing both developers and maintainers are taking issue to is that you are basically forcing the service on them, without their consent, and without proper means of opting out (for maintainers), all the while sending them mail they never asked for.
If you think making it opt-in only would kill it, then let it die. If not, why not just set that issue straight and take it forward?
it does seem that the majority of projects on tip4commit.com were added by the project maintainers and not by random fans - so implementing a feature that requires the project maintainer or authorized collaborator to explicitly endorse participation would be reasonable and would probably impact the site very little
per issue #152 - this could be implemented by sending an email to the project maintainer when someone searches/adds a project requiring them to opt-in before a bitcoin address is generated and the project becomes accessible on the live site - or the add-upon-search feature could be removed and require each project maintainer to add it themselves or not at all
@bill-auger I was just writing something similar. If it's acceptable to the open source community for an initial e-mail to be sent to 1) the maintainer to have the site added and then 2) to individual developers to ensure they are comfortable receiving tips and being on the site, I think we could migrate to opt-in. However, if these initial e-mails are seen as unacceptable then that would be an issue.
+1 kill
this could be implemented by sending an email to the project maintainer
This is sending unsolicited email and is prohibited by GitHub's ToS.
However, if these initial e-mails are seen as unacceptable then that would be an issue.
No it's not acceptable.
Broken record time again, but sending any unsolicited email to an individual developer is off-limits. If explicit opt-in before tip4commit contacts a developer would in the tip4commit team's opinion kill tip4commit, then that is the tip4commit team's choice to make. But so long as tip4commit is operating, it needs to never send unsolicited email to anyone.
This is unfortunate, but I would understand if it happened. I am very much on-the-fence about the project right now - I think it's a cool idea and I think it was made with good intentions, but it has obviously made some people very angry due to the way it was executed. This could pivot into an opt-in program for both developers and maintainers, and it would be really nice, but it doesn't seem the project founders believe in it. You know those little widgets used for Travis CI indicating build status in a github repo? Something like that would make this into a developer incentive program than can easily be plugged into any repo. If that doesn't sound interesting enough to pursue, then I don't think there is much of a future for this project.
there is a tip4commit widget - one is feature on the README.md of this repo actually
and i was not suggesting what 'should' be implemented - merely itemizing the most obvious options - in general the feature set is really an issue for the admins of individual instances to enable/disable - the problem here is that the project is still young and lacking in features and apparently experiencing some growing pains today
the biggest problem i see moving forward is that now there are several conflicting feature requests - if any are found to be unethical or whatever than they should obviously not be implemented - so the issue at hand aside from closing down tip4commit.com would be in deciding which of the conflicting options to implement - noting that there are already several instances of tip4commit variants in existence then closing down the original tip4commit.com instance may not solve anything
imho opt-in is the solution most likely to appease project maintainers, developers, and lawyers alike and i dont see how that would harm the site either in participation or in spirit - before closing tip4commit.com i would suggest implementing an opt-in feature and seeing in some time if participation drops - the value of the service would then be clear as only those who value the service will use it and those who do not can stop complaining about it
Add the freedom to opt in/out or kill the project. +1
@bill-auger the major difficulty I see is if an unsolicited initial opt-in e-mail to developers who have submitted a commit for projects approved by maintainers to be on Tip4Commit is seen as unacceptable.
I think moving to opt-in for a project to be added is pretty straightforward. If an individual searches for a project that's not already approved they get a note that the project has not been added. If they want to see it added, as an individual user or fan they can reach out to the project maintainer through whatever means they'd like as an individual and ask the maintainer to participate.
For projects where a maintainer has approved being added, it's going to be hard if Tip4Commit cannot send a message to a developer once one of their commits is accepted to ask them if as an individual they'd like to opt-in to the tipping service. If one initial message to a developer on an approved project is acceptable then I think it could be workable.
If you think making it opt-in only would kill it, then let it die. If not, why not just set that issue straight and take it forward?
@csvan , IMHO maintainers have nothing to do with tip4commit, but let's discuss it in #152 or #155
Also, consent from project mainainer doesn't imply consent from developer so there is still #154 that seems to be a more serious issue since we notify users with a single email when their balance hits the threshold. We send it only once, notification policy is explained in https://github.com/tip4commit/tip4commit/wiki/FAQ
@ubernostrum sorry for late the response, I'll discuss it with you in the ticket you created and #154
Sorry for being not able to respond to everybody in a timely fashion. I argue with you but that doesn't mean I won't do what you ask. Perhaps we'll just implement what people ask for and see if it dies itself or not. Thanks for your feedback anyway.
@ BLKSwan - you make a good point there - it is quite unclear as to what a vauge term as "acceptable" entails - my oppinion would be that any project actively accepting contributins should have clearly posted some "contribution guidlelines" - amoungst which the project maintainer could specify that "if your contribution is accepted into our codebase and is deemed worthy of a tip - you will receive an email regarding such" - in this way the term "unsolicited" woud simply not apply
@bill-auger @BLKSwan thanks for constructive approach, that could be a possible solution for the use case "Project maintainer adds project to tip4commit and attracts developers himself".
How about use cases
a) "Someone wants to tip for commits of some project one doesn't own to attract more attention from developers one doesn't know"
b) "Someone wants to get tipped for contribution to any open source project no matter what project maintainers think about it"Do they exist and can they be supported?
62 remaining items
I beleve this can be closed now
Dunno why, you still haven't killed it.
My Personal oppinion, it does not have to be killed.
And wenn it was the intent of the creators, it would have happend by now.
Since @arsenische added issue #197 (the next logical step: decentralize tip4commit) after this issue, wich also points in teh direction he changed his mind.And I notice you still haven't done that; the main site is still taking donations.
Do whatever you like, to me it's obvious the whole thing is a scam but I haven't been able to get Github to care.
They seemed to at least have fixed the legal ramifications I was talking about, this is what happens when you search for my non-commercial licensed repository. So I would vote for closing it (the ticket).
👍
Since most of the major issues are solved now, shouldn't this be closed?
Being able to delete accounts should be top priority, as under GDPR this is a huge issue for anyone in the EU. +1 for ceasing the project. If this can't/won't be done, give us the ability to delete our own accounts.
You're most likely breaking the law by not allowing people to delete their accounts on your website, do you really want to wait until you receive a formal GDPR request you won't be able to fulfil?
@alimony We do allow deleting user accounts, and we did it several times. Unfortunately it can only be done via opening an issue on github for now, but it's planned to allow it via website's ui.
@AlexandrZ How do I delete my account and why is there no info about this on the website?
@alimony you just need to ask for it on github. If you wish it can deleted it now.
@AlexandrZ Yes please.
@alimony deleted
Tip4Commit was created as a Rails Rumble 2013: http://r13.railsrumble.com/entries/410-tip4commit , it took about 48 hours and was fun. We didn't intend it to be our main project (and it is not), thought of it more of as community-driven project. So if community doesn't like it - we should kill it.
Initially Tip4Commit received mixed feedback at https://news.ycombinator.com/item?id=6916751 . But recently we received a lot of negative feedback. See https://news.ycombinator.com/item?id=8542969, #127 and the linked tickets.
If community wants to close Tip4Commit - we should identify this situation and find a proper way to close it so that nobody is offended and we don't profit from it.
Please see https://github.com/tip4commit/tip4commit/wiki/FAQ before commenting.