User:BACbKA - Revision history

Gioto at 02:20, 20 October 2011

2011-10-20T02:20:42Z

2011-02-25T17:48:43Z

filtered reports

2011-02-23T21:38:18Z

‎My GRAMPS-related scratchpad

2011-02-22T19:19:12Z

‎My GRAMPS-related scratchpad

2011-02-22T16:29:01Z

‎My GRAMPS-related scratchpad

2011-02-22T13:24:17Z

dump out random thoughts that have piled up

2011-01-18T15:15:19Z

my name and homepage

New page

[http://www.tarunz.org/~vassilii/ Vassilii Khachaturov]

@@ Line 6: / Line 6: @@
 * reports & export should have more in common -- in filtering/selecting source set and output data
 ** new action - filter, expose for cli?
-** see also bug [http://www.gramps-project.org/bugs/view.php?id=1600 #1600] and [[Filtered_Reports]]
+** see also bug #{{bug|1600}} and [[Filtered_Reports]]
 * what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:
 # two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.
@@ Line 13: / Line 13: @@
 This is a known hot issue, see [[How_you_can_help#Web_2.0]]
 - can we send out only the stuff that changed? (yet another multisync sub-problem)

@@ Line 6: / Line 6: @@
 * reports & export should have more in common -- in filtering/selecting source set and output data
 ** new action - filter, expose for cli?
-** see also bug [http://www.gramps-project.org/bugs/view.php?id=1600 #1600]
+** see also bug [http://www.gramps-project.org/bugs/view.php?id=1600 #1600] and [[Filtered_Reports]]
 * what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:
 # two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.

@@ Line 6: / Line 6: @@
 * reports & export should have more in common -- in filtering/selecting source set and output data
 ** new action - filter, expose for cli?
 * what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:
 # two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.

@@ Line 8: / Line 8: @@
 * what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:
 # two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.
-# make life easy for people taking periodic exports from gramps - can we send out only the stuff that changed? (yet another multisync sub-problem)
+# make life easy for people taking periodic exports from gramps

@@ Line 5: / Line 5: @@
 * auto-translation of names, places, etc. - for reports and exports
 * reports & export should have more in common -- in filtering/selecting source set and output data
 * what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:
 # two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.
 # make life easy for people taking periodic exports from gramps - can we send out only the stuff that changed? (yet another multisync sub-problem)

← Older revision		Revision as of 13:24, 22 February 2011
Line 1:		Line 1:
	[http://www.tarunz.org/~vassilii/ Vassilii Khachaturov]		[http://www.tarunz.org/~vassilii/ Vassilii Khachaturov]
		+
		+	=My GRAMPS-related scratchpad=
		+	* merge familylines and relgraph good stuff into a common report
		+	* auto-translation of names, places, etc. - for reports and exports
		+	* reports & export should have more in common -- in filtering/selecting source set and output data
		+	* what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:
		+	# two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.
		+	# make life easy for people taking periodic exports from gramps - can we send out only the stuff that changed? (yet another multisync sub-problem)