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. đ
>> >>> [... 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. 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. > 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? 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. đ 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. 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. 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. Cheers, =David
signature.asc
Description: Message signed with OpenPGP
