Topics

Hackthon management/software development philosophy


 

Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.

I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.

I see the following key questions:
- How strict do we want to be following a particular system?
- How can we make sure that software/other efforts aren't duplicated?
- How can we make sure that each persons capabilities are being used effectively and in line with their interests?
- What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?

We can create a hashtag (https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.


 

Some more specific questions/suggestions:

- Expectation/requirement for CI testing?
- Expectation/requirement that people follow the Github PR workflow
(https://guides.github.com/introduction/flow/)?
- Expectation/requirement on implementation language?
- Expectation/requirement on (automatic) containerization? Standardize
on Docker or something else?
- Set up Python repo with expected directory structure, metadata, and
guides on how to set up docs/CI/etc.

On Sat, 23 Feb 2019 at 08:01, Chris Mutel via Groups.Io
<cmutel=gmail.com@groups.io> wrote:

Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.

I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.

I see the following key questions:
- How strict do we want to be following a particular system?
- How can we make sure that software/other efforts aren't duplicated?
- How can we make sure that each persons capabilities are being used effectively and in line with their interests?
- What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?

We can create a hashtag (https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.


--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################


tomas Navarrete
 

I have the impression that SCRUM is maybe a little too much when dealing with teams of less than 6 members. Luckily, we may end up being more than 6 ;)

- I think we can follow a light version of SCRUM, maybe with less stand-up meetings and more work (since our sprint may be too small). Something like Trello could be used to asign tasks/user stories and keep track of who is participating in which one.

- Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)

- As for quality, we could use sonar metrics as the tool ( https://www.sonarsource.com/products/codeanalyzers/sonarpython.html )  + define a base threshold for coverage. The drawback is that we would need to get used to do some checking before pushing code.

More importantly, I think that we must first to production and secondly to quality in this phase where we want to "see that it works".




"Chris Mutel" ---02/23/2019 08:01:52 AM---Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that

From: "Chris Mutel" <cmutel@...>
To: hackathon2019@bonsai.groups.io
Date: 02/23/2019 08:01 AM
Subject: [hackathon2019] Hackthon management/software development philosophy
Sent by: hackathon2019@bonsai.groups.io





Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.

I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.

I see the following key questions:
- How strict do we want to be following a particular system?
- How can we make sure that software/other efforts aren't duplicated?
- How can we make sure that each persons capabilities are being used effectively and in line with their interests?
- What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?

We can create a hashtag (
https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.


 

On Mon, 25 Feb 2019 at 09:33, tomas Navarrete <tomas.navarrete@...> wrote:

I have the impression that SCRUM is maybe a little too much when dealing with teams of less than 6 members. Luckily, we may end up being more than 6 ;)

Thanks Tomas. As you seem to know what you are talking about here, can I nominate you as the head of this working group?

- I think we can follow a light version of SCRUM, maybe with less stand-up meetings and more work (since our sprint may be too small). Something like Trello could be used to asign tasks/user stories and keep track of who is participating in which one.

Can we use Github projects (https://github.com/BONSAMURAIS/hackathon-2019/projects)? Just to keep things simple?

- Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)

- As for quality, we could use sonar metrics as the tool ( https://www.sonarsource.com/products/codeanalyzers/sonarpython.html )  + define a base threshold for coverage. The drawback is that we would need to get used to do some checking before pushing code.

If we follow the pull request workflow, then there is no drawback - hopefully you get things right the first time, but have a chance to see the code quality reports before merging into the master branch. This has worked well for me in the past, as I always seem to forget something...


tomas Navarrete
 

+1 for Docker ... but, on which components ? The RDF server + database ?

+1 also for the PR workflow (this is a defacto standard)

As for language, no one will deny that python is almost a de facto standard around the community, but we must not forget that the point is using the right tool for the right job.
Testing, quick prototyping in my mind is very easy with python (hence it's de facto standard). It requires much less boilerplate to be up and running. The downside would be in the docker side: miniconda3 images are huge compared to a java runtime


+1000 setting up the python repo with directory structure metadata. Like this, providing testing scripts would be easier, as well as letting others the option to work on forks and accept PRs after right code review.

This last point seems important to me because it will help to identify the concrete deliverables ;)


"Chris Mutel" ---02/23/2019 09:05:11 AM---Some more specific questions/suggestions: - Expectation/requirement for CI testing?

From: "Chris Mutel" <cmutel@...>
To: hackathon2019@bonsai.groups.io
Date: 02/23/2019 09:05 AM
Subject: Re: [hackathon2019] Hackthon management/software development philosophy
Sent by: hackathon2019@bonsai.groups.io





Some more specific questions/suggestions:

- Expectation/requirement for CI testing?
- Expectation/requirement that people follow the Github PR workflow
(
https://guides.github.com/introduction/flow/)?
- Expectation/requirement on implementation language?
- Expectation/requirement on (automatic) containerization? Standardize
on Docker or something else?
- Set up Python repo with expected directory structure, metadata, and
guides on how to set up docs/CI/etc.

On Sat, 23 Feb 2019 at 08:01, Chris Mutel via Groups.Io
<cmutel@...> wrote:
>
> Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.
>
> I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.
>
> I see the following key questions:
> - How strict do we want to be following a particular system?
> - How can we make sure that software/other efforts aren't duplicated?
> - How can we make sure that each persons capabilities are being used effectively and in line with their interests?
> - What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?
>
> We can create a hashtag (
https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.
>



--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################





Bo Weidema
 

My skills are probably best suited for working on the formalisation of the ontology, as outlined by Matteo.

Bo

Den 2019-02-25 kl. 09.33 skrev tomas Navarrete:

- Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)
--


tomas Navarrete
 

under the SCRUM methodology, we would also need a product owner: someone capable of prioritizing the user stories / tasks

"Bo Weidema" ---02/25/2019 09:58:03 AM---My skills are probably best suited for working on the formalisation of the ontology, as outlined by

From: "Bo Weidema" <bo.weidema@...>
To: hackathon2019@bonsai.groups.io
Date: 02/25/2019 09:58 AM
Subject: Re: [hackathon2019] Hackthon management/software development philosophy
Sent by: hackathon2019@bonsai.groups.io





My skills are probably best suited for working on the formalisation of the ontology, as outlined by Matteo.

Bo

Den 2019-02-25 kl. 09.33 skrev tomas Navarrete:

    - Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)
--