---
# System prepended metadata

title: Schedule for the Hackathon

---

# Schedule for the Hackathon

[![hackmd-github-sync-badge](https://hackmd.io/FOu6L9mUTeWfhtQJRCbz4g/badge)](https://hackmd.io/FOu6L9mUTeWfhtQJRCbz4g)

---

4.5 hours

18:30-23:00 UTC

11:30-16:00 PT

14:30-19:00 ET <br/><br/>

| Timing UTC/PT | Activity |
|-----------------| --------------------------------------------------------------------------------------------------|
|18:30 / 11:30am | General introduction of the workshop timeline, objectives, recommended behaviour, and session organizers|
|18:45 / 11:45am | Short introduction about the power of Git and Github, about the experience of session organizers, and question period |
|19:05 / 12:05pm | Explanation and assignment of participants and organizers to breakout rooms|
|19:15 / 12:15pm | **BREAK** |
|19:25 / 12:25pm | Collaborate in breakout rooms (minimum 3 people per room). See breakout room details below.
|20:25 / 1:25pm  | **BREAK**|
|20:35 / 1:35pm  | Breakout room summary and group discussion. Each group reports back in 5-10 min|
|21:30 / 2:30pm  | **BREAK** |
|21:40 / 2:40pm  | Closing and next steps  |
|22:00 / 3:00pm  | *optional* start manuscript outline in breakout writing rooms|
|23:00 / 4:00pm  | **END** |

---
### Breakout room details
#### Participants can choose from one of 5 breakout rooms
1) Visualizing data and results
2) Career-supporting resources
3) Research documentation
4) Programming and code support
5) Dynamic collaboration

#### *Within* each breakout room, we'll cover the following topics:  
Step 1: Presentation of the breakout room topic  
Step 2: Exposition of examples AND/OR individual/collective practice session  
Step 3: Discussion and summary of challenges  
Step 4: Return of participants and organizers to the main workshop room  

#### *Within* each breakout room, consider the following discussion questions:
1) What other tools have you used for this purpose?
2) How does GitHub compare to other tools you've used for this purpose?
3) What are the main challenges in using GitHub for this purpose?
4) What are the main benefits of using GitHub over some other tool?
5) What could be done to improve GitHub for this purpose?
	

#### What questions do we want to address during the discussion?
1) How often do you see GitHub being used in these ways in ecology and evolution? Any examples come to mind? (Examples can be useful to include in manuscript outline)
2) Do you think ecology and evolution would be improved with more usage of these tools? In what ways? 
3) What parts of ecology and evolution are beyond the scope of these tools? And provide example (e.g., _____ is a better platform for _____.)
4) What parts of ecology and evolution are put at risk by these tools? *e.g. concerns about scooping/data security*
5) (*If you work in Eco/Evo*) Would you consider using GitHub for any of your current or future projects, or recommend it to your colleagues? If so, what would you most want to use it for (visualisation, documentation, etc.)?

### Writing rooms
1) General paper organization
2) Figure brainstorming
3) Blog post brainstorming

### Notes

*How do we plan to use github going forward?* Check out our padlet responses [here](https://padlet.com/rcrystalornelas/zb9pgsbk8krxjdvb)!

Working with EcoEvo people it is apparent that the use of GitHub is predicated by the use of R and other programming languages. Instead of using 3rd party data management. A lot of emphasis in R based tools, but highlight all the things that you can do on GitHub that have nothing to do with R.

There is reluctancy from students and PIs or collaborators in using GitHub. Reasons:

- lack of time, not worth the effort.
- Baby steps to start using GitHub:
Example: "Learn how to use issues first." 

Make clear that it is really hard to make mistakes on GitHub.

Demoing the benefits of learning and all the time that you will eventually save if you learn. Initial investment is hight byt payoff is really high too.

There are so many tools available and it is hard to choose.

Fear of getting in touch with a new language.

It is not taught in colleague yet as a basic course.

Top down resistence as opposed to bottom up resistence.

Many things can be done from the desktop graphical user interface.

PIs afraid to be scooped. Solutions:
- Private repo, going public upon publication.
- Licensing.
- Terms of use.
- You actually have premise once you publish it.
- You wil have more citations.

Fear of being so open, kind of vulnerable, everybody will see all your errors.

Difference between code peer review and paper peer review. One is easier than the other  

Eco-evo specific version of https://doi.org/10.1371/journal.pcbi.1005510

Methods in Ecology and Evolution.

https://besjournals.onlinelibrary.wiley.com/doi/10.1111/2041-210X.13652

No body really knows all the possibilities that GitHub has to offer.

Maybe make a chart of tools, list what they have to offer and then compare to GitHub.

Goal: take the angle of things that you can do with version control, either GitHub or any other tool.