I agree 100% with what Pablo said! - Rami
On Mon, 7 May 2018, 00:14 pablo pita leira, <pablo.p...@pitagoral.com> wrote: > Well, I am no mail expert and I am not confronted with the distributed > case. As a user, my modest use case is that I want to have control of my > private email, and as I know Java, I like to be able to work with the > server if I like to implement something. > > Respect the first point, I need some solution to keep a few gigabytes of > email which I can deploy in a Linux server easily. For me, ideally I > would want a mail James package that I could upgrade to new releases > easily. > > And respect the second one, the code base makes the product work, and > gives the chance to adapt for whatever case is needed among many of > them. The code base is huge because of the great amount of choice, and > makes understanding of the parts more complex. Therefore, I am for > simplifying the code base by removing less used options, or having them > separate. And of course, documentation is helpful as a new user to start > with the server. As developer, quickly setup an environment to start > hacking is welcome. In my case, I have no docker experience, and I am > used to run applications the old way. > > I think the simple mail server use case is important for single > developers to try and test new features. The distributed use case with > kubernetes makes it a bit harder for me (I do not have experience with > that technology). Requirements for companies are at another level, > indeed. But many marketing features for James would sell both groups > fine, single users and companies. > > I do not think current capabilities of the server are well promoted so > better communicating the current features would be good to get more > users to try the server. Maybe a sort of marketing campaign releasing > some smart things people could quickly do with the server would be nice. > > That was my 2 cents. > > > El 06/05/18 a las 08:31, Eric Charles escribió: > > Hi James Community, > > > > We have just discussed on the private list actions to further gain > > users and developers on the Apache James mail server. > > > > The discussion started as we are slow to convert new contributors to > > committers and we have a slow release schedule. > > > > I will summarize key points we have discussed. This is just a base to > > start the discussions and we really would love and need to hear your > > voice on this. > > > > 1. DOCS and TUTORIALS > > > > - We have a new website but no easy tutorials. > > - Which platform to use (readthedocs...?) > > - Migrate/Close Wiki. > > > > 2. NOT ENOUGH HANDS? DROP NOT ENOUGH USED COMPONENTS > > > > - We may have to do some choice: Drop some Mailbox implementations > > (JCR, HBase), some data backends (JCR, HBase, JDBC) > > > > 3. FULLY DISTRIBUTED > > > > - Today James features (multiple mailbox implementations, configurable > > mailets, jmap access...) may not be enough to make the diff. > > - It sounds like a fully distributed solution (potentially running on > > Kubernetes) could be a better differentiator. There is still work to > > achieve this (especially on the queuing level). > > > > 4. GSOC > > > > - GSOC is an great way for new contributors, > > - Any other options to attract newbies? > > > > 5. COMMUNICATION > > > > - We don't use enough the available communication channels: Twitter, > > Apache Blog... > > - We also don't communicate between us about the plans, pipeline... > > This is an action to fix this. Do we need to put a kanboard in place? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > > For additional commands, e-mail: server-dev-h...@james.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > >
