-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build Next Generation Reprohack Infrastructure #10
Comments
Pinging @bast. We can use this issue as a starting point for planning development. Feel free to edit summary or add more thought in this issue. |
This looks very good! Thank you! I really like these points (summarizing them just to make sure I understood):
Comments
For me this point is not so important. The ReproHack organizer looking through submissions and possibly giving feedback/help and clicking the green button is not a big hurdle and I think I like that a human is looking of a submission and not only a bot. Also the page may get both "normal" pull requests to fix typos or some details and paper submissions and I think we don't need too much automation here. Questions
|
IIUC future ReproHack organizers would have to do these steps:
|
Plan updates: We have decided to address this issue as well as #6 #8 #10 & #11 by building a custom dynamic website for the project using Django. RequirementsForms for collecting data from/on:
Website will serve:
Benefits:
I am planning on working on this on our RSE Sheffield Hacktoberfest and should have a prototype online by 2019-10-22. |
Help with Django skills welcome!! |
I can help out with that and brush up my Django ... But how will Reprohack organizers deploy the Django services in practice? |
So....my django knowledge is so limited that I don't even know what Django services are 😂. But the idea is that once users have authenticated, they will be able to submit events or edit submitted ones. We will provide the standard text for an event as a default but they will be able to edit and customise it. Here's what the draft events form looks like atm: |
I started by following this tutorial and slowly building it up to suit our needs: https://tutorial.djangogirls.org/en/django_admin/ |
OK sorry my question was vague - what I meant is this: to run a Django site, the organizers will have to run a Python web server, either self-hosted or hosted somewhere. This can take some setting up. I only raised this because I would like to make sure that this is not a barrier for those who do not know how to set this up or do not have the resources. |
Ahhh ok got you!
So they won't need to recreate the site at all, all they would need to do is submit the details of their event and then they will have their own page on the main Reprohack site!
And for starters we'll be hosting the site on a University of Sheffield VM.
Does that make sense?
…Sent from my iPhone
On 18 Oct 2019, at 11:11, Radovan Bast ***@***.***> wrote:
OK sorry my question was vague - what I meant is this: to run a Django site, the organizers will have to run a Python web server, either self-hosted or hosted somewhere. This can take some setting up. I only raised this because I would like to make sure that this is not a barrier for those who do not know how to set this up or do not have the resources.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Got it - one site hosted in a central place that can be used for spin-off Reprohacks. That's great! |
One of the goals is to make ReproHacks reproducible, ie develop customisable templates and tools so that hosts can run ReproHacks easily.
Problems with current setup
The current approach to event setup & delivery uses shiny and googledocs to compile a list of papers and collect feedback for the authors. This approach comes with limitations:
Solutions
Manage everything through GitHub:
Taking inspiration from Carpentries workshop website deployments for event sites, and rOpenSci management of package reviews to track reproductions and feedback to authors, we will be developing a system that is fully open and relies solely on GitHub for compiling and serving paper lists as well as tracking reproductions and participant feedback. Managing everything through GitHub also means we have a way of contacting authors through their with needing to publicise email addresses
Use pull requests for paper submissions
Make pages static and build after checks pass
This way we minimize the toolset and would not require Google Forms etc. Having everything in one place (one repository) would also simplify reuse for other events. Generate from a GH template and that's it: no other accounts and places to set up.
Use participant registration issues for author feedback
This helps maintain everything in the same place and can be handled by expanding the current GitHub issue template. Although the majority of authors submitting to the CarpentryConnect the fact that feedback will now also be open might put some people off initially. This makes a really clear and well enforced code of conduct, particularly with respect to treatment of authors even more important!
Use bots/tests to automate some processes?
Key considerations
The text was updated successfully, but these errors were encountered: