Do we need a web app for adding registry datasets and members?

[rachaelgallagher]

I am keen to make sure new members who are not skilled in Git can join the network and/or add their datasets to the registry easily. @jmadin, @bmaitner @jhpoelen discussed the creation of a simple web app for this on Skype last week with differing opinions. My vote is for an app with the same fields as we already ask for in the members.md and for a Registry app with the fields in issue #30 . What do others think?

[rachaelgallagher]

Any new datasets added will be subject to a quick review process before going live. In this way, new members will have more interactions with members of the OTN and we can encourage involvement.

[jhpoelen]

Perhaps we can create a bot that automatically prepares a new dataset/member file from form entry and create associated pull-request. This way, we'd avoid sync issues and having to build another admin workflow.

[rachaelgallagher]

@iimog would like a list of taxonomic expertise for all members for the Members page. In the context of this issue, we may also want to add another field to the yml for expertise

[jhpoelen]

so:

1. web app presents form
2. user enters info
3. web app generates dataset.md / member.md file
4. web app creates pull request for review

[rachaelgallagher]

sounds like a good plan, similar to what @jmadin was advocating.

[jhpoelen]

Excellent. Perhaps we can simply re-brand the subscribe page to a registration page and do submission by email using some email list. Curious to see how this is going to pan out.

[rachaelgallagher]

Yes - the subscribe page is redundant anyway, but not sure what you mean by "do submission by email using some email list". More details?

[jhpoelen]

1. user enters registration info on web form
2. user clicks "register"
3. email with registration info is sent to info@opentraits.org
4. inbox info@opentraits.org is forwarded to otn editoorial member emails

[rachaelgallagher]

Ah - thanks, I see now. Sounds good. I don't currently have the skills to make this happen, but am keen to learn alongside

[jhpoelen]

Not quite sure who built the current form, but it uses mailchimp. Looks like they allow for customization, perhaps we can use that for our registration workflow.

https://mailchimp.com/help/add-a-signup-form-to-your-website/
https://mailchimp.com/help/create-a-hosted-signup-form/

[rachaelgallagher]

(removed creds)

[rachaelgallagher]

Though @jmadin did also make a basic sign-up for the Registry in heroku already; https://afternoon-tor-83256.herokuapp.com/login I'll investigate mailchimp options, but let's see what solutions he already has in place in coraltraits.org that could be easily adapted.

[jhpoelen]

In my effort to do the least possible, I was thinking to add a link to info@opentraits.org with a pre-populated subject + body for member and dataset registration. If we can't keep up we can always invest in automation.

[jmadin]

@jhpoelen @rachaelgallagher . Apologies for the absence. I think we should hold back on getting too complicated with this GitHub solution, otherwise we may as well be spending the time on a web app. The web app will allow us to really take something like this to the next level.

That heroku app you referred to above, rach, was about two hours of work from start to development at heroku (I didn't pay for the hosting, which is why it's so slow to load initially). I think I just imported a spreadsheet from @caterinap trait standard paper. Most of the things we're trying to do at GitHub are already baked-in to these "on rails" frameworks, including user accounts and emailers.

[jhpoelen]

While I agree that heroku + rails is a great combo (github is a rails app ;) ), I think we should not underestimate the effort required to develop and maintain a change controlled, collaborative environment, cdn hosted, automatically deployed solution that github + github pages offers out of the box. So, far our github pages site consists of some html templates, a few versioned data files and a javascript file to select photos.

However, I'd be happy to help if you feel strongly about re-implementing the site in rails on heroku. Perhaps a candidate for #28 ?

[jmadin]

I don't feel strongly about it at all. But if people want more than simple, then let's do it properly. I'll take a look at the doc in #28. Thanks for starting that.

[jhpoelen]

I agree on doing things properly after we get this first minimal site up and running. How/when would you like to proceed with architecture discussions? Would you like to help organize?

[jhpoelen]

Would an issue template be a "cheap" interim solution?

https://github.blog/2016-02-17-issue-and-pull-request-templates/

[jhpoelen]

also see https://help.github.com/en/articles/creating-issue-templates-for-your-repository

[rachaelgallagher]

@jhpoelen @jmadin we're at a bit of an impasse here I think. Seems a decision hinges on whether we have the resources (i.e. people hours) to dedicate to taking the site to a new level, or if we proceed with a solution that allows the site to be functioning when new members and datasets begin to flow (presumably once the paper is out). An architecture discussion seems like a good idea at this point, but it would help to know your bottom-lines on this issue at this stage. Personally, I prefer a solution that makes it simple to interact with the site when becoming a new member of registering data and it seems a web app is the solution there. But, if I'm understanding correctly @jhpoelen you're also potentially advocating for a template for pull requests that would be embedded in the site for new users to populate? [please bear with me as I learn as we go here]

[jhpoelen]

@rachaelgallagher yep, I am advocating for pre-populated issues/pull requests .

[rachaelgallagher]

@jhpoelen right - for now as a quick solution or as an ongoing plan?

[jhpoelen]

@rachaelgallagher template should be quick/easy to try. If it stick keep it, if not try something else. I can see the re-using issues for reviews and discussions being handy.

[rachaelgallagher]

Right - thanks @jhpoelen I think it's logical to have a simple solution in for now and then progress an architecture discussion before embarking on a better solution in the style of coraltraits.org @jmadin does this seem reasonable to you?

[jmadin]

Yes absolutely. Sorry for causing a fuss. I think I saw something about creating bots to interpret emails to create md files somewhere, and thought that went over a line.

One more question: does this mean someone has to approve all these pull requests? If so, it means someone is spending time doing this. Just to think about.

[jhpoelen]

@jmadin @rachaelgallagher thanks for being patient with all these crazy ideas floating around.

I agree it takes work and time to review the datasets to be added. I think it might help us build a groups of reviewers, build a community (I've already made a GloBI contact via #40 (comment)), vet the quality of the registry, and version control changes.

And yep, it'll be a ton of work when we get tons of submissions. That'd be excellent, because then we'll have a reason to ask for help/money/time and we'll have some experience to try something new when we get it.

I am getting a bit carried away. . . please help me get back to earth. . .

[rachaelgallagher]

@jmadin Ha! no fuss at all! I'm enjoying seeing different ideas and plans taking shape for the OTN platform. Crazy ideas are great @jhpoelen -I am reluctant to bring you back to earth! I think ideally we'd try to find funding to develop the next phase of the registry, but perhaps this is in the sights of @iimog at the iDiv meeting in April? Either way, I like the idea of a set of curators for particular taxonomic groups who review submissions. I think this is also done in coraltraits where there is a curator for each trait (maybe I have this incorrect?)

[jhpoelen]

Now that we have the editors team and a way to direct to submit requests, we'll hopefully have a steady stream of pull requests (updates) and issues (new items) coming in. I'd be happy to handle some of the work, and am wondering how to distribute the work. Any ideas?

[rachaelgallagher]

Yes - it's unsustainable for a small group to be handling all requests. Ideas: (1) I now have a better idea of who is a GitHub user we could approach people directly, (2) put out a general call via email to ask for editors; (3) recruit new members specifically for editorial roles via the twitter account? @bmaitner is always a fan of doing this.

[jhpoelen]

@rachaelgallagher Your outreach ideas sound pretty good to me. Curious to hear ideas from @bmaitner @iimog @jmadin on how to establish an active editorial team. Should we have incentives to join OTN editorial team? Like unlimited free coffee at the next workshop?

[bmaitner]

@rachaelgallagher we're currently sitting at 789 followers on twitter, I'm sure at least some of them will be happy to help! Regarding incentives, I think that being a more active member in the network will come with some very important perks: higher authorship on group manuscripts, higher priority for workshop/meeting attendance/funding, and being able to help shape the network itself! Plus, you know all the newest resources if you're an editor!

Beyond that, perhaps editors could be highlighted on the members page somehow? A section or a badge or something? Plus you get something to add to the "service" bit of your CV ;)

[jhpoelen]

I took some time today document member and dataset registry processes at https://github.com/open-traits-network/open-traits-network.github.io/tree/master/_members#readme and https://github.com/open-traits-network/open-traits-network.github.io/tree/master/_datasets#readme respectively.

Much like @rachaelgallagher and @bmaitner ideas to recruit editors. I leave it up to you to take action.

Closing this issue: So, the current consensus is that we'll use github's existing web services (e.g., issues, web-based editor, version control) for now. I am sure there'll be betters ways to do things, and I am hoping we can make the best to guide contributions into a nicely curated registry.

[rachaelgallagher]

Thanks Jorrit! I will get moving on recruiting editors

…

________________________________ From: Jorrit Poelen <notifications@github.com> Sent: Thursday, 10 October 2019 2:45 AM To: open-traits-network/open-traits-network.github.io <open-traits-network.github.io@noreply.github.com> Cc: Rachael Gallagher <rachael.gallagher@mq.edu.au>; Mention <mention@noreply.github.com> Subject: Re: [open-traits-network/open-traits-network.github.io] Do we need a web app for adding registry datasets and members? (#37) I took some time today document member and dataset registry processes at https://github.com/open-traits-network/open-traits-network.github.io/tree/master/_members#readme and https://github.com/open-traits-network/open-traits-network.github.io/tree/master/_datasets#readme respectively. Much like @rachaelgallagher<https://github.com/rachaelgallagher> and @bmaitner<https://github.com/bmaitner> ideas to recruit editors. I leave it up to you to take action. Closing this issue: So, the current consensus is that we'll use github's existing web services (e.g., issues, web-based editor, version control) for now. I am sure there'll be betters ways to do things, and I am hoping we can make the best to guide contributions into a nicely curated registry. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#37?email_source=notifications&email_token=AEJQ6N43Q5XSUXJNTRMUZS3QNX4BHA5CNFSM4I4BUUC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYK55A#issuecomment-540061428>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEJQ6N7NF34LUGWGSEPXCGTQNX4BHANCNFSM4I4BUUCQ>.