You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by David Leangen <ap...@leangen.net> on 2020/06/14 03:46:44 UTC
Regarding "Users"
Hello Apache James Community!
As you may know, I became interested in James and wanted to learn about how to set up my own mail server. My main interests in James are (1) the admin api and (2) the ability to extend via Mailets. I was intending to use James as a “User”, and not necessarily get involved with "development”. (I use quotes because I now realize that I am using my own personal definition of these terms, as I explain below.)
I figured that my complete and utter ignorance of James actually gave me an advantage in that I could see things from a brand new “User’s” perspective that long-time community members may no longer see. I could be that annoying person who points out when the emperor has no clothes. 😇
To that end, in the spirit of open source, I have been trying to contribute back in the form of writing documentation, a task that developers often don’t have the time or desire to do. 😆
Several people have been helping me, but I would like to especially point out Benoit and Matthieu for their numerous interventions. Thanks!!
Anyway, I need to ask some blunt questions that will determine how I go from here.
First of all, I have come to the conclusion that we need a more precise definition of a “James User”:
* What is meant by “James User” (as opposed to “Developer")?
* What technical knowledge and skills are required of a "User" to "use" James?
* What level of investment is required in order to “use” James?
* What are the infrastructure and operational requirements expected of a “User” to “use” James?
* What does it even mean to “use” James?
Finally, what is the intention going forward regarding “Users”? To what extent will the James community support (or not) these “Users”?
I think the answer to these questions will help me determine my path forward.
Cheers,
=David
Re: Regarding "Users"
Posted by David Leangen <ap...@leangen.net>.
> In my opinion…
Thank you for the informative reply!
I will wait to see if anybody else provides an opinion before I respond.
Cheers,
=David
Re: Regarding "Users"
Posted by David Leangen <ap...@leangen.net>.
> Please consider using the Persona terms for the above, as to not over
> load the "user".
I know the term “Persona” in marketing. It is used for target market segmentation and product development. From how I have seen it used (at least in a Lean Startup context), is usually posed as a hypothesis against which the product is developed, and updated as the business gets feedback from the market. Personas are usually representative and quite abstract. Nobody really expects an actual person to exactly fit the persona, as it is just an approximation to help build the “right” product.
I am not entirely sure that is what we are doing here. At least, that is not quite the same as what I was proposing. (But maybe it is something that we need to do?)
I was thinking more about “roles” in the domain sense, which ought to be quite well defined since they are part of the James “contract”. We provide a list of requirements that the Operator must (implicitly) agree to, and set expectations as to who should be able to use the system. On our side, so long as the Operator respects this contract, we (the community) keep our end of the deal. Everybody happy.
I’ll have to ponder this to see if there is any overlap. On the surface there are some similarities, but I get the impression that the objective is different.
Cheers,
=David
Re: Regarding "Users"
Posted by Eugen Stan <eu...@netdava.com>.
Hi,
La 15.06.2020 13:41, David Leangen a scris:
>> I prefer the term "operator" to "user”.
> That’s fine. So I will collapse all those previous definitions into the single “Operator”.
>
> When we say “User”, it will therefore mean:
>
>>> * Email User
>>> - Just uses email without any notion of what server is providing the service
+ 1 . I would also propose we call these (Operator, Email user,
Extension Developer, Developer) as "personas" in the docs
(https://en.wikipedia.org/wiki/Persona#In_marketing): Operator persona,
or Developer persona.
When we talk about the specific persona, we have in mind the list of
abilities he/she posses and what we expect him/her to be able to do.
> I think it’s better to have two different words rather than the same word + a qualifier.
>
> On that note, if we can find different words for these, it would be nice:
>
> * Extension Developer
> * Core Developer
How about "Extension Developer" and "Developer" .
A note, some developers are also Apache contributors.
>> +1, we need to build a common terminology, and document it somewhere
>> else that just in a mail thread.
> I will include it in the new documentation. I will add a section entitled “James User Model”.
Please consider using the Persona terms for the above, as to not over
load the "user".
We can also link to what we mean by persona.
>> If the contract don't exist it can't be respected :-)
> As we say in English: “touché". (We have so many great words in English.)
:)
>> 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 think I understand what you mean, and it’s a good point.
>
> However, this is a separate topic, so I will move this to a separate thread. :-)
+1 for separation and the word change.
"Support" implies quite a lot.
"Offering" sounds good to me.
>> I perfectly agree to write an ADR for the offering, and evaluate the
>> work required to get there.
> After I produce the new docs and get some feedback, I will write the ADR.
I think things are shaping up nicely and I like it.
>
> Cheers,
> =David
>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Regarding "Users"
Posted by David Leangen <ap...@leangen.net>.
> I prefer the term "operator" to "user”.
That’s fine. So I will collapse all those previous definitions into the single “Operator”.
When we say “User”, it will therefore mean:
>> * Email User
>> - Just uses email without any notion of what server is providing the service
I think it’s better to have two different words rather than the same word + a qualifier.
On that note, if we can find different words for these, it would be nice:
* Extension Developer
* Core Developer
> +1, we need to build a common terminology, and document it somewhere
> else that just in a mail thread.
I will include it in the new documentation. I will add a section entitled “James User Model”.
> If the contract don't exist it can't be respected :-)
As we say in English: “touché". (We have so many great words in English.)
> 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 think I understand what you mean, and it’s a good point.
However, this is a separate topic, so I will move this to a separate thread. :-)
> I perfectly agree to write an ADR for the offering, and evaluate the
> work required to get there.
After I produce the new docs and get some feedback, I will write the ADR.
Cheers,
=David
Re: Regarding "Users"
Posted by Tellier Benoit <bt...@apache.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Regarding "Users"
Posted by David Leangen <ap...@leangen.net>.
> 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.
* 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.
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. :-)
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.
Cheers,
=David
Re: Regarding "Users"
Posted by Eugen Stan <eu...@netdava.com>.
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.
Regarding the Testing server, there is a niche for a product in this area.
See https://github.com/mailhog/MailHog and https://ethereal.email/ .
I would love to see something like that built on top of James with JMAP.
I think it provides a very good test-bed and has values to a lot of
developer teams working / testing email delivery.
Regards,
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Regarding "Users"
Posted by Tellier Benoit <bt...@apache.org>.
Le 15/06/2020 à 13:43, David Leangen a écrit :
>
>
>> An extension developer is a special kind of user, who understands and
>> leverage James extension mechanism (so yes).
>
> Makes sense! And I like the term “Extension Developer” as opposed to “(James) Developer”.
>
> I am currently “User”, but I want to soon become an “Extension Developer”. For me it would be much nicer to have a more minimalistic environment to develop my extensions, with maybe some kind of testbed. It would not be very nice to have to get the entire James universe working just to develop a tiny extension…
>
> But that will come later. Just thinking out loud.
Raphael and I discussed about the opportunity to re-brand the
memory-guice server as "Testing server" to come and complete the
"Demo/Basic/Advanced/Distributed" offer.
I think it could fit that role.
Cheers,
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Regarding "Users"
Posted by David Leangen <ap...@leangen.net>.
> An extension developer is a special kind of user, who understands and
> leverage James extension mechanism (so yes).
Makes sense! And I like the term “Extension Developer” as opposed to “(James) Developer”.
I am currently “User”, but I want to soon become an “Extension Developer”. For me it would be much nicer to have a more minimalistic environment to develop my extensions, with maybe some kind of testbed. It would not be very nice to have to get the entire James universe working just to develop a tiny extension…
But that will come later. Just thinking out loud.
Re: Regarding "Users"
Posted by Tellier Benoit <bt...@apache.org>.
An extension developer is a special kind of user, who understands and
leverage James extension mechanism (so yes).
Le 15/06/2020 à 13:02, David Leangen a écrit :
>>> * What is meant by “James User” (as opposed to “Developer")?
>> In my opinion a user is someone running James. He don't compile nor
>> write James related code.
>
> So does this mean that writing code for a Mailet or a Listener or whatever is done by a “Developer”?
>
> Or would a “Mailet Developer” be a special case of a “User”?
>
>
> Cheers,
> =David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Regarding "Users"
Posted by David Leangen <ap...@leangen.net>.
>> * What is meant by “James User” (as opposed to “Developer")?
> In my opinion a user is someone running James. He don't compile nor
> write James related code.
So does this mean that writing code for a Mailet or a Listener or whatever is done by a “Developer”?
Or would a “Mailet Developer” be a special case of a “User”?
Cheers,
=David
Re: Regarding "Users"
Posted by Tellier Benoit <bt...@apache.org>.
Le 14/06/2020 à 10:46, David Leangen a écrit :
> Hello Apache James Community!
>
> As you may know, I became interested in James and wanted to learn about how to set up my own mail server. My main interests in James are (1) the admin api and (2) the ability to extend via Mailets. I was intending to use James as a “User”, and not necessarily get involved with "development”. (I use quotes because I now realize that I am using my own personal definition of these terms, as I explain below.)
>
> I figured that my complete and utter ignorance of James actually gave me an advantage in that I could see things from a brand new “User’s” perspective that long-time community members may no longer see. I could be that annoying person who points out when the emperor has no clothes. 😇
>
> To that end, in the spirit of open source, I have been trying to contribute back in the form of writing documentation, a task that developers often don’t have the time or desire to do. 😆
>
> Several people have been helping me, but I would like to especially point out Benoit and Matthieu for their numerous interventions. Thanks!!
>
>
> Anyway, I need to ask some blunt questions that will determine how I go from here.
>
> First of all, I have come to the conclusion that we need a more precise definition of a “James User”:
>
> * What is meant by “James User” (as opposed to “Developer")?
In my opinion a user is someone running James. He don't compile nor
write James related code.
This can range from a hobbyist wanting a self hosted server to companies
relying on James.
> * 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.
> * What are the infrastructure and operational requirements expected of a “User” to “use” James?
Ranging from laptop for demo to a (small) VM for production server.
> * What does it even mean to “use” James?
For me the term "user" refers to "running code", and should be different
from "end user" whose mail are on James and will interact with it via
mail protocols.
The fact of using James should IMO be transparent to the end user.
> Finally, what is the intention going forward regarding “Users”? To what extent will the James community support (or not) these “Users”?
IMO:
- Regarding "end user", we are willing to support bugs within the mail
protocol implementations
-Regarding "code runner" we should of course have a deep look on their
issue, given enough detail for issue reproduction and logs are provided.
>
> I think the answer to these questions will help me determine my path forward.
That's for sure, and I believe this is an important question.
>
> Cheers,
> =David
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org