Hello, I have added a few questions and answers to the wiki, about stuff that caused me long hunts when trying to set up dovecot with maildir storage. Some of it I have gleaned from the source. Some of it is actually already documented, but I had not been able to spot it when I needed it. At the time of writing I had a particular advantage: I did not know, or had mostly forgotten, the peculiarities of the imap protocol. I say 'advantage', because I think that when writing documentation it is important, yet difficult, to see things from the perspective of a user that is quite ignorant, although not stupid. These need the documentation most, and they are in majority. (Some will say the "stupid" ones are in majority, but writing for them is almost futile anyway. Anyway, I doubt they are a majority; average intelligence is adequate for all normal tasks. What we often judge and condemn as "stupidity" is most often the result of a different perspective that _we_ are too limited to understand.) Since I am not yet too spoiled, and yet recently had my hands (or rather my eyes) in the source, this may be a golden opportunity to produce some more documentation. I therefore urge you to suggest what I should look at and write about. Do you have any ideas about how the documentation should be organized? some questions are not strictly dovecot or even imap questions, yet they arise quite naturally for an administrator that is migrating to dovecot or to imap in general. The existing migration documentation was not as usefull to me as it could have been because I was both migrating to imap from a non-imap solutions, and from mbox to maildir, both at the same time. That placed me in a particularly "ignorant" position. It is quite likely that much of what I write is not exactly true. I have suggested procmail as a delivery agent for maildir stores, because it is the only one I know about at the moment. I just occurred to me that I have not even checked if /bin/mail (on GNU/Linux systems) can do it. Any ideas? I have not (yet) found out anything about the CONTROL= part of the mail environment. Should I write something about it? Is it usefull for system administrators to know about it? What is it? Regards -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 2005-07-18 at 20:03 +0200, Enrique wrote:> I therefore urge you to suggest what I should look at and write about. Do > you have any ideas about how the documentation should be organized? some > questions are not strictly dovecot or even imap questions, yet they arise > quite naturally for an administrator that is migrating to dovecot or to > imap in general.I've been thinking of doing some major wiki restructuring some day before v1.0 release. So that in main page there would be something like: 1. Information about IMAP, POP3, SMTP and mail servers in general 2. Installing and setting up a simple Dovecot installation 3. Full guide to setting up a new system 4. Migration from existing systems - other servers - mbox <-> maildir - pop3 -> imap 5. Troubleshooting 6. Supported features / current status / TODO Troubleshooting should start with generic "How do I find out what the problem is?" and then several subsections with specific problems. I'm not sure if any of this helps with what you wanted to write though, since it is going to be a pretty large change.. :)> I have not (yet) found out anything about the CONTROL= part of the mail > environment. Should I write something about it? Is it usefull for system > administrators to know about it? What is it?It'd be useful to know since with maildir that's pretty much the only way to reliably implement filesystem quota (set Dovecot's control and index files to a partition without quota enforcing). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050722/25310402/attachment-0001.bin>
May I suggest - lots of real world examples. You can't have too many examples. And one thing to remember is that the programmer never had to learn the program. It's easy to forget that other people don't know certian things. Good docs drastically cuts support email and if you get it right all you'll be getting is feature requests and spam. ;)
> I've been thinking of doing some major wiki restructuring some day > before v1.0 release. So that in main page there would be something like: > > 1. Information about IMAP, POP3, SMTP and mail servers in general > 2. Installing and setting up a simple Dovecot installation > 3. Full guide to setting up a new system > 4. Migration from existing systems > - other servers > - mbox <-> maildir > - pop3 -> imap > 5. Troubleshooting > 6. Supported features / current status / TODOMay I suggest an additional section with a full breakdown of what every configuration directive does? Thanks, -- Nick Maynard nick.maynard at alumni.doc.ic.ac.uk http://www.fluffybrain.com
On Fri, 22 Jul 2005 16:57:19 +0200, Timo Sirainen <tss at iki.fi> wrote:> On Mon, 2005-07-18 at 20:03 +0200, Enrique wrote: >> I therefore urge you to suggest what I should look at and write about. >> Do >> you have any ideas about how the documentation should be organized? some >> questions are not strictly dovecot or even imap questions, yet they >> arise >> quite naturally for an administrator that is migrating to dovecot or to >> imap in general. > > I've been thinking of doing some major wiki restructuring some day > before v1.0 release. So that in main page there would be something like: > > 1. Information about IMAP, POP3, SMTP and mail servers in general > 2. Installing and setting up a simple Dovecot installation > 3. Full guide to setting up a new system > 4. Migration from existing systems > - other servers > - mbox <-> maildir > - pop3 -> imap > 5. Troubleshooting > 6. Supported features / current status / TODO > > Troubleshooting should start with generic "How do I find out what the > problem is?" and then several subsections with specific problems. > > I'm not sure if any of this helps with what you wanted to write though, > since it is going to be a pretty large change.. :)Oh that sounds like a nice plan. I just did not know what I wanted to write, I just wanted to have a realistic hope that anybody would care about what I write. But of course, I will also have to do a good deal research to get it nearly right.> >> I have not (yet) found out anything about the CONTROL= part of the mail >> environment. Should I write something about it? Is it usefull for system >> administrators to know about it? What is it? > > It'd be useful to know since with maildir that's pretty much the only > way to reliably implement filesystem quota (set Dovecot's control and > index files to a partition without quota enforcing).But this does not sound like the most urgent need. Perhaps I should start with number 1. above, to expose all my ignorance about the subject right from the start, and get all your friendly kicks and blows. Then I would be almost qualified to write something for number 2, the most demanding of all, from a pedagogical point of view. In the mean time somebody could begin sketching 3. and parts of 4 you happen to know something about. (I now have a first-hand experience in mbox->maildir, using formail and procmail - and a script too.) Are there any issues with clients worth mentioning? On Mon, 25 Jul 2005 12:33:24 +0200, Nick Maynard <nick.maynard at alumni.doc.ic.ac.uk> wrote:> May I suggest an additional section with a full breakdown of what every > configuration directive does?Oh, dear! Just five minutes, and it's done! But jokes aside, it's a damned good idea. While points 1-6, and especially 2-4 are perhaps more usefull in real life, not having said breakdown feels rather frustrating. Could I suggest a thing? Could you have an explicit call on new users to write a few words about their experiences and frustrations with Dovecot, whatever they are, some place where they are likely to see it? Something like "Please tell us a few words about your experiences with installing and using dovecot! Newbies are also welcome." - and a large textbox below, and a submit button. Perhaps a question too: "What is the single piece of information that could have saved you most effort and time if you only had known it early on?" I don't exactly mean a wiki page, because I think about it more like a surview, not that many would bother to read tons of trivial observations. But given the present infrastructure, perhaps a wiki page is the easiest. You may think a mailing list is for just that, but then the threshold is too high, and you never find out what most people do in real life. -Enrique -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/