I opened the following ADR to better define "quality levels" https://github.com/apache/james-project/pull/219
Please have a look ;-) Le 21/06/2020 à 13:03, Tellier Benoit a écrit : > > > 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
