Custom project locations

[hbons]

The previous implementation was buggy and not very flexible or user friendly. With the new GNOME design (#1774) we'll be able revisit this feature and add some proper UI for this.

[colonelpanic8]

@hbons Do you not see a pattern in that users of sparkleshare are consistently frustrated with your decision making, and taste wrt the ability to add advanced configuration options to SparkleShare? See #1716 #1028.

You often say things like "i don't see a reason to do it", even when there are plenty of users describing prefectly reasonable use cases and reasons for doing what they want to do.

You clearly have a mindset of "Making things as simple as possible" and "Solving for the 90% case" with SparkleShare, but you grossly overestimate the actual cost of adding these features. It makes me really sad to say that my frustrations with SparkleShare have gotten to the point where I simply can't continue to use it (#1716 is simply infuriating to me, as is SparkleShare's refusal to offer true plain text config that can be managed with dotfiles). Fragmentation is generally a bad thing in the open source community, and it is something that I am against in principle, but your refusal to cater to the needs of users who have taste and needs that are different that your own is frustrating enough to me that I am planning to write my own git auto-syncer that caters to my needs. It feels like such a waste to have to do this as it really would not be hard to make some small changes to sparkleshare to do what I want.

I realize that I probably represent a really small contingent of users, and that the vast majority will not care about the issue that I do. I still think its important for you to understand that you are alienating some people with your tyrannical stewardship.

[mairin]

@IvanMalison just fork it. Hylke is an exceptionally talented designer-developer and his choices have been great in my opinion, and in any case it's his code and it's his call. Forking seems like the best option for you right now. Good luck!

[andrewshadura]

@mairin, I don’t think it is fair to reply like that to a bit of healthy criticism @IvanMalison posted. SparkleShare arguably has its downsides and sometimes bugs and sometimes design mistakes, and @IvanMalison has a right to be unhappy about them. He obviously did post it in good faith, and he said himself he would rather have those things fixed in SparkleShare rather than having to fork it.

[davelab6]

@andrewshadura I think @mairin is completely correct both in the substance of her response and in her tone; I think you are attempting https://en.wikipedia.org/wiki/Tone_policing and I encourage you to reflect on that.

[andrewshadura]

@davelab6, your understanding is incorrect, I am not attempting tone policing. My comment wasn’t directed at the tone, but at the substance of the message. When a user is frustrated that they (and other users with similar needs) are not being listened to, then do it yourself-style replies are not helpful, and make the frustration even more substantiated.

Hylke may be exceptionally talented, but even exceptionally talented people make mistakes. And while it is true it is his code, I doubt he develops it for himself only, and he probably wants it to be used by others, so ultimately he needs to listen to their needs (and he does so, but as you can see there are cases when users are still unhappy). If users feel they’re not being listened to, probably something went wrong in the communication somewhere.

[davelab6]

Fair enough; that was how I understood your comment, "to reply like that".

Ivan said "your tyrannical stewardship" which is, like, how this works. The tyranny of a 3rd party developer is entirely mitigated by a freedom-respecting license, because it provides for you to leave the unjust kingdom and be your own tyrant.

It really is not hard to make some small changes to sparkleshare to do what he wants, in a fork. There's a big old "fork" button at the top right of this page.

[prokoudine]

@andrewshadura

When a user is frustrated that they (and other users with similar needs) are not being listened to, then do it yourself-style replies are not helpful, and make the frustration even more substantiated.

Jesus, what a bunch of entitled toxic nonsense.

Here, I'll say this in simple words and all caps, just for you.

LISTENING AND AGREEING ARE NOT THE SAME THING.

LISTENING AND DOING AS YOU SAY ARE NOT THE SAME THING.

Got it, Andrew? Did all caps help? Should I use it more? Good.

Now that I got your attention, let's talk the real deal.

It looks like you are a late arrival to the wonderful world of free software that is full of fairy dust and rainbow-shitting ponies. So let me lecture you about how this ecosystem operates, Andrew.

Free/libre software is free/libre for a reason. It's to give you every right to study and modify the code to your liking. To truly own the software. It's what adults do, Andrew: they own things.

Do you know what owning means? Owning something means having the right to use it to its full potential. Adapting it to your needs. Adapting yourself to it, when need arises.

SparkleShare is available under the terms of GPL. Did you ever read the license, Andrew? Do you UNDERSTAND what it really means? It means you effin own this piece of software, Andrew. Yes, you do. Here you are, enjoy it. It's yours, forever. But you don't — I repeat — YOU DON'T OWN THE DEVELOPER.

Because slavery is verboten. We don't do that to people anymore, Andrew. We've outgrown it. We've moved on, and so should you.

Annoying people into submission — and this is exactly what your comments feel like — is not very far from beating people into submission. Same violence, just using words instead of fists. Violence is not how you encourage developers to do things for you. It is utterly disrespectful. We should've outgrown it too by now, but thanks to pals like yourself we've yet to arrive there.

Now, repeat after me:

WE ARE A FREE SOFTWARE COMMUNITY

WE ARE GIVERS

WE ARE A RESPECTFUL BUNCH

WE DON'T ANNOY PEOPLE WHO DON'T DO WHAT WE ASK THEM FOR

IF WE CAN'T HAVE IT, WE FIX SHIT OURSELVES OR MOVE ON

So let's be respectful, for the motherloving ponies.

[colonelpanic8]

Ivan said "your tyrannical stewardship" which is, like, how this works. The tyranny of a 3rd party developer is entirely mitigated by a freedom-respecting license, because it provides for you to leave the unjust kingdom and be your own tyrant.

Yes, I am aware of this. Which is exactly why I say I plan on doing in my post...

I will say that I think you can have unilateral power without ruling over things tyrannically. I implore anyone to give a defense of the idea that @hbons puts forward here (https://github.com/hbons/SparkleShare/issues/1716#issuecomment-325460391) that adding an option to disable sparkleshare's conflict resolution would be too complicated or difficult to maintain.

There's this pretty sweet control structure called the IF STATEMENT that I think might be just the tool for something like this...

Obviously @hbons has the right to do as he pleases... I am aware that this is how it works. I was trying to give him some constructive criticism about his fetishization of design simplicity which has caused frustration (and not just from me...see the issues linked in my first post and elsewhere) in several cases.

It really is not hard to make some small changes to sparkleshare to do what he wants, in a fork. There's a big old "fork" button at the top right of this page

Yes but that sort of fragmentation has historically been very harmful in the open source community. I would generally be happy to do that sort of thing, but my concern would be with maintenence and dealing with integrating changes that come down the line.

Sparkleshare is written in C#, which wouldn't be a dealbreaker for me if I were just contributing the features, but dealing with integrating changes and maintaining my own fork that I would, in all likelihood be the only user of sounds less than ideal.

Again, my hope with this post was not to start a flame war, or to belittle @hbons, it was to offer some constructive criticism and start a discussion. In my opinion, the people responding to my post are the ones who are taking the conversation off topic (not discussing the matter at hand) and changing the conversations tone to have an ad-hominem flavor.

[fooishbar]

@IvanMalison you're really claiming to offer 'constructive criticism', followed two words later by 'fetishization'? In which parallel universe is that constructive?

[andrewshadura]

@IvanMalison, I agree with Daniel on this, your choice of words makes it difficult to perceive your comments as constructive. You should avoid using antagonising expressions like ‘tyrannical stewardship’ (which I didn’t notice at first — and which I think is too strong an expression) or ‘fetishisation of design simplicity’ (which I find unacceptable in a polite conversation); there are better ways of making your point.

@prokoudine, I didn’t read your message past the sentence with the word ‘toxic’. Caps lock and unsubstantiated accusations are not how I prefer to communicate with other people.

[prokoudine]

@andrewshadura , so you did read past the word "toxic". Great. I hope you are ashamed of yourself.

[andrewshadura]

@prokoudine, as I said, I did not. I saw lots of caps and scrolled through. I’m not interested in reading what looks like a rant. I have nothing to be ashamed of.

[davelab6]

give a defense of the idea that @hbons puts forward here (#1716 (comment)) that adding an option to disable sparkleshare's conflict resolution would be too complicated or difficult to maintain

How complicated a software development task is, or how difficult, are very subjective measures. The old kernel developer phrase, "with enough eye balls all bugs are shallow", speaks to this - with a large enough developer community, even the most deep and hardcore can be fixed in an afternoon. The even older idea of "computer wizards" comes from this super high variance in power, where a sufficiently more experienced person can walk up and woth the ease of waving their hand do something that had seemed impossible.

Since he wrote the syncing and CR system, and since the responsibility and cost of maintenance in this repo is entirely on him, then if he says it is too difficult for him, then that is his lived experience and no one can deny that or take it from him.

If it is not so difficult for you and you want to wrote the patch to realise it, then you already are forking the project in your local private copy; and to submit the patch as a pull request on GitHub, you are publishing your fork.

If you choose not to make a PR, or your PR is rejected, that's totally fine, I think.

Indeed if you maintain a good relationship with the project, you may see a PR to it's readme that links to your fork for the benefit of those interested.

That happened to a project I initiated, www.GitHub.com/Microsoft/font-validator

fragmentation has historically been very harmful in the open source community.

What harm do you believe results from the greater variety of software in the software freedom movement?

Again, for me this is the whole point. With proprietary software, there is no variety, just monoculture that is the direct consequence of each developer having a monopoly over the software I run. With free software, there is a beautiful bloom of various implementations of each computing idea, because we are free.

Fragmentation is the whole point, because consolidation is actually tyranny.

[colonelpanic8]

@IvanMalison you're really claiming to offer 'constructive criticism', followed two words later by 'fetishization'? In which parallel universe is that constructive?

I will concede that the word 'fetishization' is perhaps strong language, but I don't think the sentiment there is not constructive. I genuinely believe that @hbons seems to value 'convention over configuration', and optimizing for the lowest common denominator to a fault.

Wasn't someone just complaining about tone policing?

What harm do you believe results from the greater variety of software in the software freedom movement?

Try googling "why forking is bad" and you'll find plenty of answers, but here are the ones I consider to be the most significant:

• It divides the community
• It causes confusion for end users
• forces contributors to decide which project they want to contribute to
• It makes merging and patching significantly more difficult

Sometimes, when the philosophical differences between subgroups in the community are very great, forking is the right answer. I absolutely do not think that is the case here.

. With proprietary software, there is no variety, just monoculture that is the direct consequence of each developer having a monopoly over the software I run. With free software, there is a beautiful bloom of various implementations of each computing idea, because we are free.

You can have freedom WITHIN a software product too. If you write good abstractions its not hard to have flexible software that can behave in different ways depending on the needs of the user.

You should avoid using antagonising expressions like ‘tyrannical stewardship’ (which I didn’t notice at first — and which I think is too strong an expression) or ‘fetishisation of design simplicity’ (which I find unacceptable in a polite conversation); there are better ways of making your point.

Okay, point taken. I'm just frustrated that @hbons has taken what is, in my view, a rather extreme measure of saying "No I will not accept a contribution to my project to make it do what you want it to do." for reasons that to me objectively do not make sense. Before everyone jumps all over me for saying that, I 100% realize that it is his prerogative to do so. That doesn't mean that I'm not right that his attitude towards potential contributions has been harmful to the community.

[colonelpanic8]

How complicated a software development task is, or how difficult, are very subjective measures.

I don't know about the VERY part there, but it is true that the perceived difficulty of software development tasks can vary from person to person. With that said, I think there are cases where you can definitively, say things like "this is not a difficult task", or in this case "the proposed change will not contribute to the maintenance burden of the project".

Since he wrote the syncing and CR system, and since the responsibility and cost of maintenance in this repo is entirely on him, then if he says it is too difficult for him, then that is his lived experience and no one can deny that or take it from him.

Why are we talking about lived experience or denying or taking things from people? This isn't a social justice issue, it's a conversation about software.

If it is not so difficult for you and you want to wrote the patch to realise it, then you already are forking the project in your local private copy; and to submit the patch as a pull request on GitHub, you are publishing your fork.

If you choose not to make a PR, or your PR is rejected, that's totally fine, I think.

It's less than ideal for a few reasons:

• It means that every time I install it on a new machine, I need to build from source because I need to use the version with my changes on it. SparkleShare has quite a few dependencies that would also need to be installed manually. This is significantly less practical than just using a package manager like pacman or chocalatey to handle installing it for me.
• I would need to manually merge changes in to my own fork periodically if I wanted to get the latest versions of sparkleshare.

One thing I want to make super clear about my compliant is that I have offered to do all of the work myself. It's not like I'm going to @hbons and saying "I DEMAND THIS FEATURE". I'm offering to make a contribution, which, by the way, other users have expressed interest in, and he is saying "I won't accept your contribution". Again obviously it is his prerogative to do so, but turning away contributors is a rather extreme measure, that should (in my opinion) not be taken lightly. If I were to make such a move for one of the several open source projects I maintain, I would still be open to dialog with the prospective contributor, and I certainly would not be as dismissive as @hbons was in #1716.

[hbons]

I'm going to lock this issue, but I do like to say a few words.

@IvanMalison Your response does not honour this project's Code of Conduct. I understand you may feel disappointed that I don't find your feature suitable for the project, but that is no reason to respond in the way you did. Personal attacks and insulting comments (thinly veiled as "constructive criticism") are not acceptable.

I should really end it here, but on the technical matter (#1716); I do feel a need to clarify: the reason SparkleShare was created is to help those who need to interact with Git but can't or don't want to use the command line tools. A feature request that proposes the Git command line tools as a solution works actively against that goal by taking future maintenance time away. There were other occasions in the past where I've accepted these edge case "one-liner" solutions to make people happy. But more often than not this would cause unintended side-effects or prevent improvements at some later stage and I had to disappoint and remove the feature later on. On the issue I've acknowledged the problem, the community suggested a solution to improve the way conflict handling works and I've implemented that. I treat every contribution and issue with respect. When the reason behind a request is not immediately obvious to me I try to find the deeper reason behind it, and will provide alternative solutions where possible.

Lastly, it is ironic to complain about "not listening to users" on an issue that was created to complete the popular feature request you linked to. I've created a new issue (1851) to track this work without all this noise.