search

bssw-tutorial / tutorial-management

An issues-only repository for overarching management of BSSw tutorial development and presentation
0 stars 0 forks source link

Discuss how (whether?) to make better use of GitHub tools #39

Open bernhold opened 2 years ago

bernhold commented 2 years ago

My vision when I setup the issue and project board structure for the tutorials was that issues and issue notifications would be a primary means of communication among the team, and especially for informing the tutorial leader when things were ready, etc. and streamline interactions.

The experience with a couple of tutorials now is that its not working the way I envisioned. Engagement with the issues or the board has been very limited. A few discussions via comments, but in many cases, assigned issues are not addresses, not closed, etc. In practice, we're tending toward email and meetings for confirmations, feedback, etc.

So I'd like to have a discussion with the team as to what would be the most effective way to manage the production of tutorial events.

bernhold commented 2 years ago

@adubey64 has indicated that she has a hard time navigating the multiple repositories, etc. Does this information https://github.com/bssw-tutorial/tutorial-management/blob/main/README.md help at all?

Would it help if we consolidated all issues into a single repository and used a project board in that repository instead of an organization-level board? The down side would be that it becomes harder to connect issues and PRs, and PRs still have to be dealt with on a per-repository basis (though so far, we're mostly doing direct commits rather than PRs).

bernhold commented 2 years ago

One of the concerns for the person leading the tutorial is tracking everyone's progress in individual tasks like updating presentations, resources, or hands-on instructions, or making recordings. I'd like to have a way that everyone agrees to use to track progress in these kinds of things. There are multiple ways to use Github issues for this. One issue per task (i.e., for each presentation that needs to be updated). One issue for every step in the process with an internal checklist for each individual task within the step). In some cases, pull requests would be a logical approach. All of these approaches have disadvantages. One issue per task leads to many tasks to sort through, although it is possible to script the creation of the issues (this is in the website repo already). One issue per step doesn't provide notifications when checklist items are checked off. PRs work as long as something in the repo needs to be changed -- presentations that don't need updating, or recordings which are too big to put in the repo, won't result in PRs and will still need some other form of communication.

I should note here, that there are two key points to this, from my perspective. One is to try to reduce the number of back and forths required in email to keep track of everyone's progress. GH notifications for closed issues or opened PRs can serve that purpose. If everyone agrees to use checklists within issues rigorously, I can at least check in one place for progress and don't need to bug people who have completed their tasks. But the second is that I need a means to track what needs to be done so that we don't forget things. I need some way of having a complete list of the tasks that need to be done at every step and be able to check on their status. So even if we decide that the easiest thing for the presenters and other contributors is email, there's still going to be a checklist in some form that I will use.

adubey64 commented 2 years ago

@bernhold it also might be that I need to become better acquainted with github and the repos and get a map in my head about relation between repos. Let us revisit this in Feb.

bernhold commented 2 years ago

The utilities section of the tutorial events now include scripts to create github issues for both the tutorial organizer(s) and presenters. Not everything is there yet, but most of the primary things are.

bernhold commented 2 years ago

Right now, we're generating one issue per presentation for most things that need to be done by the presenters. A question is whether that's the right granularity or would it be better to have one issue per presenter with a checklist of the presentations they're responsible for?

I asked about this in email and so far have one vote for the per presenter approach and one considering the two to be equivalent. More feedback would be welcome.