Le 15/06/2020 à 16:09, David Leangen a écrit :
>
>> I think it's a good discussion toe establish the terminology and have
>> the same view of this.
>>
>> I hope it gets into the docs as a term deffinition or something similar.
>>
>> +1 for Extension Developer.
>
> I am thinking something like:
>
> * James User
> - Does not compile any code
> - Does not require an IDE
> - Has some basic knowledge about email protocols
> - Has some basic knowledge about how James works (from the docs)
> - Can perform some relatively simple configurations
> - Has basic knowledge of mail architecture (protocols), and basic sysadmin
> skills
>
> This implies:
> - They do not build a server… must use a provided server
> - They will only use the provided configurations
> - They may use the Admin API
> - They will not use Mailets or any other extensions
>
> By the way, when I originally started the documentation, I also included the
> roles of “Operator”, “DevOps” etc. With this updated definition of “User” I
> think that none of these are necessary anymore.
I prefer the term "operator" to "user".
>
> * Email User
> - Just uses email without any notion of what server is providing the
> service
>
>
> * Extension Developer
> - Develops Mailets / extensions
> - Uses a lightweight development environment that we provide
> —> Does not require the core codebase
>
> * Core Developer
> - Anybody who compiles James
> - Anybody who wants to contribute to James
> - Anybody who wants to otherwise work with the James codebase
>
>
>
> Does that sound about right? I will of course think more about the wording.
+1, we need to build a common terminology, and document it somewhere
else that just in a mail thread.
>
> I think we also need to clarify the support that the James community commits
> to offering and I think somebody should make an ADR (or whatever it’s called,
> hehe)
so that this becomes the “contract” that the community strives towards.
I think that at this time, that contract is not being respected. :-)
If the contract don't exist it can't be respected :-)
>
>
> So far Benoit has proposed:
>
>>> * What technical knowledge and skills are required of a "User" to "use"
>>> James?
>>
>> I would expect them to have a basic knowledge of mail architecture
>> (protocols), and basic sysadmin skills.
>>
>>> * What level of investment is required in order to “use” James?
>>
>> Low. I expect them to download James, adapt ~10 lines of configuration,
>> run ~10 cli command and be able to use it straight away.
Joke aside, that applies of course for documented use cases.
Also I would like to differentiate the terms "offering" (what do we
deliver as part of the James project, who do it targets, and how easy
should it be to use) from the term "support" which in my view implies
"how fast you solve my problems", and might be a more sensible topic.
I perfectly agree to write an ADR for the offering, and evaluate the
work required to get there.
Cheers,
Benoit
>
>
> Cheers,
> =David
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
