Improvements to issue/PR labeling/management

[carreter]

Now that I am a collaborator on the repo and have access to do these things, I want to help organize the repo more and make it easier for new contributors to hop on and for existing contributors to see what needs to be worked on.

Issue/PR automations

I would like to set up a few different things to improve how we manage GitHub issues and PRs:

• Mark newly created issues with the triage label
• Add priority labels (high priority, normal priority, and low priority) to issues
• Add ability for issues/PRs to be blocked by other issues/PRs
• Mark issues as stale after 2 months of inactivity
• Close stale issues after 1 month of inactivity not doing this per @Koeng101 's request
• Automatically mark draft PRs with the draft label realized this is redundant
• Set up a more fleshed-out PR template
• Add ourselves to https://goodfirstissue.dev/ so more people can find us
• Allow users to assign themselves to an issue
• Create tags and push releases on merge to main. (do we want to do this on merge to a release branch instead?)
• get go docs to automatically pull in new tag on release.
• Help wanted discord channel that announces when a github issue is tagged with a help wanted label. This seems to be broken on Discord's end, I've submitted a bug report.
• Document all these workflow changes in CONTRIBUTING.md #375

Changes to our workflow

This will require some changes to our workflow that I will document in CONTRIBUTING.md:

• All newly created issues (which will be labeled with triage) must be manually triaged by a collaborator on the repo to ensure they are properly labeled
  • IMO, the triage process should require marking the issues with a priority (high priority, normal priority, or low priority), an assignee or the help wanted label, one or more issue type(s) (bug, enhancement, documentation. ux, windows, question), and a difficulty (easy, intermediate, or hard).
  • The triage label could be automatically removed once the above conditions are satisfied
• Start labeling issues as help wanted or good first issue to encourage people to contribute. good first issue is especially helpful in attracting newcomers!
• Make sure we go through stale issues and either assign them to someone to mark them as wontfix

Who is responsible for making sure these workflow changes happen?

The above tasks should be shared by all collaborators (currently: @TimothyStiles , @Koeng101 , and me - lmk if I'm forgetting anyone); I'm more than happy to take on the brunt of this since it was my idea! 😃

Open questions

These are mostly aimed at @TimothyStiles and @Koeng101 :

• Are these changes worth the effort?
• Will y'all participate in the new issue triaging workflow? If not, is there a way it could be simplified to lower the effort required?
• Are the requirements for an issue to be considered triaged and have the triage label removed reasonable? For something to be considered triaged, I believe it should fulfill all of the following:
  • Has assignee and/or help wanted label
  • Has a priority label (high priority, normal priority, or low priority)
  • Has at least one issue type label (bug, enhancement, documentation. ux, windows, question)
  • Has a difficulty label (easy, intermediate, or hard)

Once y'all answer these questions, I'll go ahead and start this!

[Koeng101]

Overall, lgtm, just a few comments!

Close stale issues after 1 month of inactivity

I don't like this. The problem is often still there, so I don't think we should close stale issues automatically.

Set up a more fleshed-out PR template

I'm not sure how well this will work - mostly because both Tim and I completely ignore the templates for issues right now anyway.

Add ourselves to https://goodfirstissue.dev/ so more people can find us

That's pretty cool! I think an inflow of contributors once we have work would be great. Representing at programming / Golang events also seems to work well as Tim has found.

IMO, the triage process should require marking the issues with a priority (high priority, normal priority, or low priority), an assignee or the help wanted label, one or more issue type(s) (bug, enhancement, documentation. ux, windows, question), and a difficulty (easy, intermediate, or hard).

This seems like too much standardization to me. In particular I don't think we can reasonably assign people work, since we'd be assigning free labor to work which feels a bit odd - especially since both Tim and I have somewhat of a financial incentive for the work (Tim using large parts of poly for bebop and I using large parts of poly for nanala's DNA design and sequencing pipelines). I think the priorities and the difficulty are quite useful though.

Start labeling issues as help wanted or good first issue to encourage people to contribute. good first issue is especially helpful in attracting newcomers!

I think we did this a little bit but then fell apart because we didn't continuously put effort into it.

Are the requirements for an issue to be considered triaged and have the triage label removed reasonable

Honestly, my eyes kinda gloss over with more than one. difficulty and priority to me seem like the perfect amount of labels, but I'd like to know @TimothyStiles take on this.

---

Overall, I think a problem is that this can help solve is that the style of work Tim and I do are along the lines of "work really hard for a minute then fuck off for a while", so there are long-ish periods of essentially inactivity between spans of hectic activity, and this could help with that if we structure it right - especially if @carreter is willing to help triage in the in-between periods.

I also think something that should be discussed more is the actual roadmap with people willing to do work. So far, development has largely been "ah shit, Keoni needs this one function" (me complaining to Tim about genbank format is literally how Poly got started). Which is great, because yay not only do I get functions I need but other people also maintain them (pure win), but also doesn't seem to be a great way to run a project in the longer-term. Mainly, I think there should be a little more focus on people (beyond Keoni and Tim) actually using the tools we build to do biology.

I do think it is doable - we have some great and honestly unique synthetic biology functions - we just need to package them correctly and get em to the right people.

[TimothyStiles]

Overall, lgtm, just a few comments!

Close stale issues after 1 month of inactivity

I don't like this. The problem is often still there, so I don't think we should close stale issues automatically.

Maybe label them stale or something to let other people know they wouldn't be stepping on toes if they picked it up or assigned themselves.

Set up a more fleshed-out PR template

I'm not sure how well this will work - mostly because both Tim and I completely ignore the templates for issues right now anyway.

Couldn't hurt. I say let's do it. Sometimes more is actually more.

Add ourselves to https://goodfirstissue.dev/ so more people can find us

That's pretty cool! I think an inflow of contributors once we have work would be great. Representing at programming / Golang events also seems to work well as Tim has found.

+1

Reminds me I'll be at GitHub universe this year as my first appearance at a mostly tech conference. Is there something we'd want to do for hacktober fest? I've also been considering running some in person stuff here in the Bay at Noisebridge since it'd be easy and near my house. Could maybe livestream it?

IMO, the triage process should require marking the issues with a priority (high priority, normal priority, or low priority), an assignee or the help wanted label, one or more issue type(s) (bug, enhancement, documentation. ux, windows, question), and a difficulty (easy, intermediate, or hard).

This seems like too much standardization to me. In particular I don't think we can reasonably assign people work, since we'd be assigning free labor to work which feels a bit odd - especially since both Tim and I have somewhat of a financial incentive for the work (Tim using large parts of poly for bebop and I using large parts of poly for nanala's DNA design and sequencing pipelines). I think the priorities and the difficulty are quite useful though.

@Koeng101 assignments are more so devs know who's working on what so we don't have to worry about accidentally stepping on each other's toes. I'm for what @carreter has proposed.

Start labeling issues as help wanted or good first issue to encourage people to contribute. good first issue is especially helpful in attracting newcomers!

I think we did this a little bit but then fell apart because we didn't continuously put effort into it.

It was actually more because GitHub used to not show anything about the repo in search except for "good first issues"

Are the requirements for an issue to be considered triaged and have the triage label removed reasonable

Honestly, my eyes kinda gloss over with more than one. difficulty and priority to me seem like the perfect amount of labels, but I'd like to know @TimothyStiles take on this.

I think they're reasonable. My only concern is how easy will it be to maintain this style in practice. Good docs are key here.

Overall, I think a problem is that this can help solve is that the style of work Tim and I do are along the lines of "work really hard for a minute then fuck off for a while", so there are long-ish periods of essentially inactivity between spans of hectic activity, and this could help with that if we structure it right - especially if @carreter is willing to help triage in the in-between periods.

I also think something that should be discussed more is the actual roadmap with people willing to do work. So far, development has largely been "ah shit, Keoni needs this one function" (me complaining to Tim about genbank format is literally how Poly got started). Which is great, because yay not only do I get functions I need but other people also maintain them (pure win), but also doesn't seem to be a great way to run a project in the longer-term. Mainly, I think there should be a little more focus on people (beyond Keoni and Tim) actually using the tools we build to do biology.

I do think it is doable - we have some great and honestly unique synthetic biology functions - we just need to package them correctly and get em to the right people.

I agree that we should be doing more to bring more devs and maintainers on board and I like what @carreter is proposing here. Better yet most of this can be easily changed if something needs to be tweaked so I say go for it!

[carreter]

Close stale issues after 1 month of inactivity

I don't like this. The problem is often still there, so I don't think we should close stale issues automatically.

Sounds good to me!

Set up a more fleshed-out PR template

I'm not sure how well this will work - mostly because both Tim and I completely ignore the templates for issues right now anyway.

I think just having it in place would be nice, I know I would definitely use it. It'd be pretty barebones, but just having something would encourage people to more explicitly document what they are changing, why they are changing it, and how they've tested it.

Add ourselves to https://goodfirstissue.dev/ so more people can find us

That's pretty cool! I think an inflow of contributors once we have work would be great. Representing at programming / Golang events also seems to work well as Tim has found.

Yes!!! IRL poly meetup when?

IMO, the triage process should require marking the issues with a priority (high priority, normal priority, or low priority), an assignee or the help wanted label, one or more issue type(s) (bug, enhancement, documentation. ux, windows, question), and a difficulty (easy, intermediate, or hard).

This seems like too much standardization to me. In particular I don't think we can reasonably assign people work, since we'd be assigning free labor to work which feels a bit odd - especially since both Tim and I have somewhat of a financial incentive for the work (Tim using large parts of poly for bebop and I using large parts of poly for nanala's DNA design and sequencing pipelines). I think the priorities and the difficulty are quite useful though.

Makes sense. This is why I was suggesting triaging require assignment OR the help wanted label - that way people know if someone is actively working on an issue or if it needs someone to pick it up. We could just make it convention that you only self-assign issues (and encourage non-collaborators to comment that they've picked something up so we can assign it to them), that way we aren't forcing work on people.

I also have a financial incentive to contribute here 😉 I don't have much of a public portfolio yet and I'm going to be entering the full-time job market in a year or two 😅

Start labeling issues as help wanted or good first issue to encourage people to contribute. good first issue is especially helpful in attracting newcomers!

I think we did this a little bit but then fell apart because we didn't continuously put effort into it.

This is always the issue with workflow changes, lol - only work as well as the amount of effort people are willing to put into it. This is why I offer to do the bulk of this administrative work.

Are the requirements for an issue to be considered triaged and have the triage label removed reasonable

Honestly, my eyes kinda gloss over with more than one. difficulty and priority to me seem like the perfect amount of labels, but I'd like to know @TimothyStiles take on this.

Makes sense! I do have a tendency to overlabel things, lol

Overall, I think a problem is that this can help solve is that the style of work Tim and I do are along the lines of "work really hard for a minute then fuck off for a while", so there are long-ish periods of essentially inactivity between spans of hectic activity, and this could help with that if we structure it right - especially if @carreter is willing to help triage in the in-between periods.

I work the same way! I blame my ADHD. And yes, absolutely willing to help triage the in-between periods - I think poly is going to be a project I stick with for a while 😀 I hate that there's basically no bioinformatics tools in a modern, typed language, and this package fits the bill for that.

I also think something that should be discussed more is the actual roadmap with people willing to do work. So far, development has largely been "ah shit, Keoni needs this one function" (me complaining to Tim about genbank format is literally how Poly got started). Which is great, because yay not only do I get functions I need but other people also maintain them (pure win), but also doesn't seem to be a great way to run a project in the longer-term. Mainly, I think there should be a little more focus on people (beyond Keoni and Tim) actually using the tools we build to do biology.

I do think it is doable - we have some great and honestly unique synthetic biology functions - we just need to package them correctly and get em to the right people.

We should definitely do a call to plan this out! I think something that might help is to change the messaging on poly a little - we are going to have (and already have IMO) utilities that are useful beyond just synthetic biology. Maybe we should brand ourselves as a more general bioinformatics or just plain biology package?

[TimothyStiles]

Holy quotes batman.

[carreter]

FEAR ME

[carreter]

Maybe label them stale or something to let other people know they wouldn't be stepping on toes if they picked it up or assigned themselves.

Yep, that's the plan! FYI, non-collaborators cannot currently assign themselves to an issue. Maybe we should change this?

Good docs are key here.

Yep, absolutely. I'll be making a new section in CONTRIBUTING.md to explain all these changes.

[TimothyStiles]

Maybe label them stale or something to let other people know they wouldn't be stepping on toes if they picked it up or assigned themselves.

Yep, that's the plan! FYI, non-collaborators cannot currently assign themselves to an issue. Maybe we should change this?

Been meaning to change this for a while. GitHub doesn't have a setting for this but maybe a bot would be good for this? I think I remember seeing a github action or two that we may be able to use for this.

[carreter]

Yep, that's the plan! FYI, non-collaborators cannot currently assign themselves to an issue. Maybe we should change this?

Been meaning to change this for a while. GitHub doesn't have a setting for this but maybe a bot would be good for this? I think I remember seeing a github action or two that we may be able to use for this.

Sounds good, will do!