Le 19/06/2020 à 20:49, David Leangen a écrit :
>
> 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.
This is a fair point, but 'quality' differs from 'support' concerns.
We of course need to refresh / clarify our expectations regarding code
quality as a all.
As part of the 3.0.0 release in 2016 we did that work and decided that
to be supported:
- 'interfaces' in components needs a contract test suite
- 'implementation' of these interfaces needs to pass this test suite
- Decent integration tests coverage is needed
- Performance tests needs to be conducted out.
- Quality Assurance with external clients
Everything not matching these standards would be categorized as
experimental.
Enforcing this for 3.0.0 (JAMES-1765) id lead us to this kind of
documents [1], in order to leverage faith in the existing components.
[1]
https://github.com/chibenwa/james-project/blob/v3.0_roadmap/v3.0_roadmap.adoc
I would add to the list:
- known existing production deployments/usages
- usable documentation
I believe the 'quality' of what we provide is independent from the
support we offer (of course better quality might bring less needs of
support).
I will write an Architecture Decision Record on this topic.
>
> Cheers,
> =David
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
