From 2f429663225e4dcd196fa4043e76bb5ac9c98007 Mon Sep 17 00:00:00 2001
From: zsloan
Date: Wed, 30 Mar 2022 11:04:21 -0500
Subject: Rename inserting_traits.gmi to inserting-traits.gmi

Didn't notice that the file-names used hyphens instead of underscores---
 topics/data-uploads/inserting-traits.gmi | 29 +++++++++++++++++++++++++++++
 topics/data-uploads/inserting_traits.gmi | 29 -----------------------------
 2 files changed, 29 insertions(+), 29 deletions(-)
 create mode 100644 topics/data-uploads/inserting-traits.gmi
 delete mode 100644 topics/data-uploads/inserting_traits.gmi

diff --git a/topics/data-uploads/inserting-traits.gmi b/topics/data-uploads/inserting-traits.gmi
new file mode 100644
index 0000000..513a2c7
--- /dev/null
+++ b/topics/data-uploads/inserting-traits.gmi
@@ -0,0 +1,29 @@
+I think this is a distinct topic from the inserting_data one, since that just mentions add new samples (or case attributes) to existing traits.
+
+Rob just mentioned adding the functionality (that apparently exists in GN1)
+to add Temp traits (through the Submit Trait page, though we could create
+a new interface) and then convert those traits to permanent traits.
+
+Below are some criteria he mentioned and comments about the existing GN1 system:
+
+- In GN1 I believe you can only do this with phenotype traits. From the
+Submit Trait page (https://genenetwork.org/submit_trait) you only select
+a group (not a specific dataset), so if you permanently add that trait
+it's just entered as a phenotype. This is probably the main (if not only)
+way people would use this feature, though, so that might be fine.
+
+- For GN2 we will need to add a curation step. GN1 actually doesn't have
+one - any logged in user could add traits! We were just lucky no one abused
+this.
+
+- The curation can probably borrow from Bonface's existing work, though there
+will need to be an extra step where it e-mails (or otherwise notifies) curator(s)
+to notify them of the change. Rob says this can just be him. It might work to
+have it just e-mail Rob, but also let the changes be viewable through an interface
+like the "datasets/diffs one" (maybe a separate "datasets/inserts" or something).
+
+- This feature should also be tied in with authentication. When a user adds a
+trait, access should automatically be restricted to just them until they open
+it up to the public. I don't think this should be that difficult; when the
+trait is inserted it's simple to run the Redis command setting them as the
+owner and the default privileges as private.
diff --git a/topics/data-uploads/inserting_traits.gmi b/topics/data-uploads/inserting_traits.gmi
deleted file mode 100644
index 513a2c7..0000000
--- a/topics/data-uploads/inserting_traits.gmi
+++ /dev/null
@@ -1,29 +0,0 @@
-I think this is a distinct topic from the inserting_data one, since that just mentions add new samples (or case attributes) to existing traits.
-
-Rob just mentioned adding the functionality (that apparently exists in GN1)
-to add Temp traits (through the Submit Trait page, though we could create
-a new interface) and then convert those traits to permanent traits.
-
-Below are some criteria he mentioned and comments about the existing GN1 system:
-
-- In GN1 I believe you can only do this with phenotype traits. From the
-Submit Trait page (https://genenetwork.org/submit_trait) you only select
-a group (not a specific dataset), so if you permanently add that trait
-it's just entered as a phenotype. This is probably the main (if not only)
-way people would use this feature, though, so that might be fine.
-
-- For GN2 we will need to add a curation step. GN1 actually doesn't have
-one - any logged in user could add traits! We were just lucky no one abused
-this.
-
-- The curation can probably borrow from Bonface's existing work, though there
-will need to be an extra step where it e-mails (or otherwise notifies) curator(s)
-to notify them of the change. Rob says this can just be him. It might work to
-have it just e-mail Rob, but also let the changes be viewable through an interface
-like the "datasets/diffs one" (maybe a separate "datasets/inserts" or something).
-
-- This feature should also be tied in with authentication. When a user adds a
-trait, access should automatically be restricted to just them until they open
-it up to the public. I don't think this should be that difficult; when the
-trait is inserted it's simple to run the Redis command setting them as the
-owner and the default privileges as private.
-- 
cgit v1.2.3