Add more docs for Feature Layer

not complete, but progress..

docs/features/people/entry/editing.rst

@@ -0,0 +1,32 @@
+
+Editing
+=======
+
+Rattail makes it possible to edit most data it contains regardless of
+its nature.  This of course includes Person-related data.
+
+However just because you *can* edit data in Rattail, does not mean you
+*should* do so.  You must keep in mind, "which system is the
+authority?" for any given data point.
+
+In other words if you import Customer records from your POS, but then
+do not configure an export mechanism to get any changes made in
+Rattail *back* into the POS system, then by far the easiest thing is
+to just not allow editing in Rattail.  But you still can view the
+data, and use various app features which leverage the data (e.g.
+:doc:`../../custorders/index`).
+
+However if you *do* configure export mechanisms then you may want to
+allow editing directly in Rattail.  This can be any data point which
+is supported by the export mechanism.  For instance if you allow
+editing of a Customer name in Rattail, the change could be synced back
+to POS.
+
+But it's also possible for Rattail to contain "more" data than the
+source (e.g. POS) system does.  For instance your POS DB may have a
+field to track the "birthday" for each Customer, but maybe you also
+need to track their "favorite color" and the POS DB does not provide a
+way to do that.  In this case you can import Customer records from POS
+into Rattail, and then allow editing in Rattail only for the "favorite
+color" field.  Best of both worlds, you can now track whatever you
+want with no need to export data back to the source system.