Ok, let me see if I can answer these questions one at a time.
git: at any given time, you'll want to be keeping up with the code in the
git repo. If you are developing against a released version of the code you
might have trouble integrating your changes.
That having been said, no open source projects are going to give commit access
to new developers right away. Initially you submit patches against the current
tree, and the maintainer (in this case, me) will evaluate each patch, and
if it is acceptable, apply those patches to integrate the new code.
After a while, you would get commit access to the tree, and even then, you
might maintain a separate branch and then make "pull requests" asking for
changes in that branch to be pulled into the master branch. But let's not
worry about that for now; just submit patch files.
Test suite: unfortunately there is none. We
hand-test everything. I suppose Uncensored could be considered the test site
:)
New features: if you have an idea, propose it right here. We can discuss
it and talk about whether a particular new feature makes sense for the system
as a whole, and if implemented, what would need to be done. Good ideas are
always welcome, especially if you're willing to write the code yourself.
I would only shy away from ideas that would compromise the system's usability
for other users.
Let's look at your two examples:
1. Flagging in IMAP
Sure, that's a great idea. So you added to `struct visit` to do that, which
makes perfect sense. Here's where I get to ask: did you look in all places
where `struct visit` is used, to see if any additional code is necessary?
For example, `serv_migrate.c` will have to be patched to add the `flagged`
element to exports and imports. `serv_expire.c`
is probably ok as-is, but check.
2. Aliasing
This is a good example of where it needs to be re-thought, in this case only
a little. Let's say you have a user "alice" with appended suffixes like
"alicebank"
and "alicespam". So far so good ... but then another Alice joins the
organization,
let's say her name is "Alice Bob" and you make her email "ali...@example.com".
Now you get mail for "aliceb...@example.com" -- is it for "al...@example.com"
with suffix "bank" or "ali...@example.com" with suffix "ank"?
I would suggest we use a separator character. I think the plus sign "+"
is often used for this. If you were to submit a patch to do suffixes, let's
make the rule that when it comes to finding the user associated with an email
address, we throw away the "+" and anything after it. We also reject new
usernames or email addresses containing a "+" in them.
Is that enough to get you started?
