On Fri, 2020-06-19 at 22:49 +0900, David Leangen wrote: > Hi, > > Please be in a good mood when you read this. Words can be taken the > wrong way. I am writing this with a big smile on my face, all in good > humour. đ
Don't be afraid, debate is sane > > > > [... snipped everything ...] > > > > I agree with everything you wrote. > > I think you are taking certain things a little too much out of > context. đ > > My point is more about being honest than being generous. I am not > trying to recruit anybody to provide free work. Not at all. > > When I say there should be some kind of SLA, I am not at all > suggesting that everybody commit a fixed amount of time or make any > guarantees to solve other peopleâs problems for free. Actually, I > thought I had proposed quite the opposite (that we list people and > companies who are willing to do it for a fee.) So it sounds like we > are very much in agreement. Nobody should be expected to work for > free if the donât want to. > > My point is about being up front and honest, so people know what to > expect and can weigh their options. In order to build trust, we need > to set reasonable expectations (whatever they happen to be), and > stick to them (or update them if we canât). Personally, I prefer when > somebody under-sells and over-delivers the somebody who does the > opposite. I can trust that person and if I agree to their terms, I > know I will be satisfied. From what I have read and based on the > people I know, I think that most people appear to be the same. > > If people donât understand their options, then the unknowns make > using James too risky. In my mind, that is not a successful community > project. When it comes to evaluate a piece of software, I don't really look at commitment: people rarely deliver what they commit to. What I look for is "how it behaves usually": are people getting answers? are problem usually get solved? how many people are active on the project? What is their direction? who uses it? Commitment is just text and I don't have much trust in text. > For instance, if the website states that that a particular feature of > James works, then it really should work. Otherwise nobody will trust > the James community. > > There are already basic standards in place and are I think being > respected, else the community would very quickly fall apart: > > * New features should have tests > * Tests should always pass > * Code should always compile > * Etc. > > I could suggest that we add a bit to that list for the sole purpose > of setting expectations and, hopefully, eventually expanding the > community. > > And anyway, is it really such a horrible thing, for instance, to ask > somebody who commits a feature to ensure that it gets documented > properly? Or that the code is readable? Etc. > > If it is too much to ask, then we should instead write disclaimers on > the website to warn people instead of trying to boast about how > awesome James is. > > > Don't like it? Don't use it. > > I donât disagree with that statement. Let me just make sure that I > completely understand with this test: if somebody dumps trash all > over a public place, then states âDonât like it? Donât use it.â I > donât think I would be very happy. True, I wonât use a park full of > trash because I donât like it, but I think thatâs an abuse of this > principle. I trust that is not what you mean, right? I am assuming > that what you mean is more along the lines of âThe suit doesnât fit? > Ok, donât wear it!" > > By all means, please go ahead and make nice suits, even if it doesnât > fit everybody. But please do not dump trash in the park. Internet is not a finite space as parks are: you can create "internet parks" at will with a single click, it's a button called "fork". What I mean is: active community members define goals for the project that matter to them, no matter what others expect. You want to influence decision? Come and contribute. By the way, it's exactly what you did: make the project change by contributing to it. If you like the software and have different goals: fork it. The only reason we care about users is because it matters to us not because they have some rights on the project. > > > I am a volunteer in the Apache Software Foundation as all of us > > are. > > Sorry⌠I took the bait and feel compelled to respond to your little > lecture. đ > > Are you really? Yes, definitely. > The definition I found was: > > > a person who does something, especially helping other people, > > willingly and without being forced or paid to do it > > Except for the âwithout getting paidâ part, I should point out that > you are stating exactly the opposite. đ I don't. I am both a volunteer and a paid contributor. > Itâs all ok. You are just being honest about your intentions: you are > in it for your own gain, not to help others. If others can benefit > from your work, great, but that is not your primary objective. Fine. Not my opinion at all. > Of course there is nothing wrong with that. My efforts to help with > documentation are not entirely altruistic, either. But you canât have > your cake and eat it, too. You canât call yourself a âvolunteer" if > really youâre just in it for yourself and others just happen to maybe > benefit. And if you really are in it to help others, then you would > be thinking of them first. There are more than two reasons to be here. I care about being paid, I care about users but I also have other motivations. I don't feel like help others should be "first". > > So yeah, letâs just be honest and set the right expectations so > everybody is happy. > > Having an SLA will help do that. We should only commit to what we are > willing to commit to, but there **must** be a clear definition of the > service level that is being offered (even if essentially says "f*** > you stupid userâ, at least thatâs clear and honest.) > > > Ok, all that was very abstract and waaaaaay off-topic, but I wasnât > expecting a reaction like the one you had so I had to have a little > fun with it. đ > > If you reread my initial message in this new light, I hope youâll > find that it was not intended to sound unreasonable. It is about > honesty and expectation setting, not free work. > > > So if we agree that an SLA is necessary (and I think we are > agreeing), then most of what you wrote (i.e. what you are not willing > to commit to) relates to what the contents of the SLA ought to be. > And what you write makes good sense in that context. > I still think it's not a good idea unless you want to handle the SLA yourself or with some other people from the community because I don't expect to have a commitment with virtually anybody at anytime. Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
