Add more docs for Feature Layer

not complete, but progress..

docs/features/people/members/index.rst

@@ -0,0 +1,80 @@
+
+Members
+=======
+
+As with Employee and Customer data, the first questions regarding
+Member data are: What is it, and what does it have to do with Rattail?
+
+Rattail's concept of a "Member" comes primarily from the world of
+retail food co-ops, where a Member is more like a Customer than an
+Employee.  But there exist also worker co-ops, where a Member is
+really more like an Employee.  Rattail's Member features are meant to
+acommodate both scenarios.
+
+Members often have some equity account associated with them, with join
+and (where applicable) withdrawal dates, and usually also a payment
+history for the equity.
+
+So if your organization has a membership component, then you most
+likely already have some way to track accounts and equity etc.  Why
+bring it into Rattail?
+
+As usual the first answer is simple visibility.  For instance you
+might be tracking accounts in a spreadsheet or Microsoft Access, or
+any of a number of similar "undesirable" solutions.  Even if you
+continue with that tracking approach, you also could periodically
+import data to Rattail just so it can be more easily viewed by others
+via the web app.
+
+And part of visibility is cross-referencing related data.  Maybe you
+already have a good way to view accounts, but you have no way to view
+an account alongside its equity, or perhaps POS Transaction history
+etc.  Showing the various types of data on one screen (maybe with a
+link back to the other system) can be quite helpful in some cases.
+
+Another potential feature is to send email reminders to Members who
+have an upcoming payment due, etc. based on their account details.
+And it's possible to monitor an IMAP folder for any "bounces" that
+result from sending such reminders, in which case can e.g. flag the
+account as having a bad email on file.
+
+Similarly a Member account status may dynamically affect which
+discounts are available to their Customer account at the POS.  This
+idea depends on the ability to effect certain changes in the POS
+system, e.g. add/remove electronic coupons for an account.
+
+But..everything just stated is technically possible *without*
+importing the data to Rattail.  So still at this point we've not
+established a good reason to actually import it.
+
+You can of course create batches for performing account maintenance in
+whatever way is needed.  Same general "rules" apply as for other
+(e.g. Customer) tables.  Member data need not be imported into Rattail
+in order to use the batch features.
+
+But unlike the Customer data, where the POS is frequently the obvious
+"authority", many times Member data is *not* tracked (well) by the
+POS, and so custom spreadsheet workflows or similar tactics are
+employed to keep track of it.
+
+So this finally is why you *might* want to import it into Rattail.
+Any tasks being managed via spreadsheet workflows (or whatever) can
+instead be managed directly in the web app.
+
+If you choose this route, a couple of implications:
+
+Rattail becomes your primary Member system, and you (presumably /
+ideally) no longer need your previous system for that, other than to
+keep it as an archive.
+
+Data is maintained directly in the web app, for instance creating a
+new Member account, or withdrawing one etc.  Also equity payments
+could be entered directly if they happen outside of the POS, e.g. when
+someone mails a check.
+
+But equity payments still likely will happen in the POS also.  And for
+this to work "seamlessly" it means Rattail must monitor the POS
+Transactions which occur, at whatever frequency is acceptable.  Near
+real-time is possible and in some cases necessary for sake of dynamic
+coupons etc.  But in other cases a nightly processing of the previous
+day's transactions may be sufficient.