proposal to fork the list (users/developers)

[Green, Paul]

I tend to be someone who automatically looks for trends, and the nice thing
about having just one list is that it lets me know where people are having
problems.  Judging by the number of questions we get, one of the biggest
challenges for inexperienced rsync users is knowing why a particular file is
included or excluded.  Way in the back of my mind I see a need for an option
that, for every file included or excluded, says which rule was used to make
the decision.  Nice and simple.

I think if the product is easy enough to use and the documentation is good
enough, then one list should be fine, because the volume should be low.
Getting lots of repetitions of similar questions is an indication that there
are usability issues with the product.  In fact, if someone has some time on
their hands, it would be a fun project to pour over a year's worth of email
and do a Pareto chart on the questions we've gotten.  (A good undergraduate
research paper topic, perhaps?)  Right away such a chart would suggest
development activities we could implement to improve the usability.

So I'm neutral/mildly-opposed to splitting. But if we do split, don't call
it "rsync-technical".  Call it "rsync-devel" or similar.  I think one of the
reasons samba gets non-development email on samba-technical is that the name
doens't give a clue as to what the list is about.

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Computer, Inc.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
Speaking from Stratus not for Stratus