Initial draft for triaging

[Sherwin-14]

This is the initial draft for the triaging document(#754). The pre-commit check is failing because of the use of format argument which seems like a necessity for rendering the doc, more on this here.

---

📚 Documentation preview 📚: https://earthaccess--901.org.readthedocs.build/en/901/

[github-actions]

👈 Launch a binder notebook on this branch for commit 7b7f1aa

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit 4145cfe

👈 Launch a binder notebook on this branch for commit a7a182c

👈 Launch a binder notebook on this branch for commit 9e876f3

👈 Launch a binder notebook on this branch for commit aa815ff

👈 Launch a binder notebook on this branch for commit b04d16f

👈 Launch a binder notebook on this branch for commit 827d79c

👈 Launch a binder notebook on this branch for commit a9c8ea8

👈 Launch a binder notebook on this branch for commit 70f2f42

👈 Launch a binder notebook on this branch for commit 70edb3d

👈 Launch a binder notebook on this branch for commit 0b939b6

👈 Launch a binder notebook on this branch for commit e53370f

👈 Launch a binder notebook on this branch for commit ed81270

👈 Launch a binder notebook on this branch for commit 5ce45af

👈 Launch a binder notebook on this branch for commit f41f79c

👈 Launch a binder notebook on this branch for commit 6c4df6b

👈 Launch a binder notebook on this branch for commit a2029a5

👈 Launch a binder notebook on this branch for commit a953c0e

👈 Launch a binder notebook on this branch for commit c89cb13

👈 Launch a binder notebook on this branch for commit cabf675

👈 Launch a binder notebook on this branch for commit 393df4a

👈 Launch a binder notebook on this branch for commit cf51bad

👈 Launch a binder notebook on this branch for commit 48c9f05

[mfisher87]

Nice work! Will look more closely this week.

Looks like there's a tradeoff to be considered here to fix linting with --unsafe: https://github.com/pre-commit/pre-commit-hooks#check-yaml

[asteiker]

I'm wondering if some updates may be needed based on the recently closed #760 ? If it would be helpful for me to review and update accordingly, I'd be happy to help.

[mfisher87]

@asteiker that would be super helpful!!

[mfisher87]

@asteiker OK to assign this PR to you?

[mfisher87]

🙌 Amazing work! Sorry about the number of suggestions here -- we re-organized labels in #760 to be more self-describing, and I think that helps make this document more clear!

[mfisher87]

@asteiker can you also take a look?

[Sherwin-14]

@mfisher87 Hey Matt, what about PR triaging workflows? Wouldn't they also be included in the triaging doc?

[mfisher87]

I'm not sure exactly what you mean here; are you thinking about PR reviews?

[Sherwin-14]

I'm not sure exactly what you mean here; are you thinking about PR reviews?

Yeah PR reviews workflow(I confused it with PR triaging), there is a flowchart for that as well in the repo you linked, should we add that as well to our triaging guide?

[mfisher87]

I think it's a great idea! But I would also like to keep this PR focused and get it merged without too much delay. What do you think about dealing with that in another PR?

[mfisher87]

@Sherwin-14 I'd like to wait to review until the ReadTheDocs build is working again. Do you feel comfortable fixing it? Details here: #901 (comment)

[Sherwin-14]

I think it's a great idea! But I would also like to keep this PR focused and get it merged without too much delay. What do you think about dealing with that in another PR?

Sounds good to me :). I also have added the mermaid dependency.

[mfisher87]

In a rush, just leaving comments :)

[mfisher87]

I'd like to add back the "good first issue" label, perhaps alone in a "Special labels" section? That is one that triagers should be especially aware of!

[mfisher87]

bot will auto close if no update has been made in 3 days

I think this isn't true. We have one automation for autoclosing issues, but I believe it's broken: https://github.com/nsidc/earthaccess/blob/main/.github/workflows/issue-manager.yml

We should be careful about fixing it: #895 & https://jacobtomlinson.dev/posts/2024/most-stale-bots-are-anti-user-and-anti-contributor-but-they-dont-have-to-be/

[Sherwin-14]

Hey, I did not made changes to the flowchart since we had discussed earlier, that flowchart will be reviewed. so that is why a lot of irrelevant info is still up there.

[mfisher87]

Ah, that makes sense, thanks for the context! I forgot 🙃

[Sherwin-14]

So how do we move forward from here? I know there might some specific suggestions that you may have in your mind. I think we can encompass all of those in a single review, so it becomes easier for me to add them to the PR :)

[mfisher87]

I think getting @asteiker 's eyes on this is probably the best way forward. Will you be at next week's hack day? Maybe we can work together to finalize the flowchart.

[asteiker]

@mfisher87 @Sherwin-14 Apologies for my radio silence on this recently! Yes I am happy to get back into this and work together at the next hackday. I'll review this in more detail in preparation.

[mfisher87]

Thanks, Amy!

[mfisher87]

Renders as

[mfisher87]

We don't have priority levels yet to my knowledge. @asteiker what do you think?

[asteiker]

@mfisher87 I really like the idea of priority levels for our bugs. In fact, I have been playing around with this in a new GH project view (see priority column: https://github.com/orgs/nsidc/projects/10/views/5). I don't believe this priority would be visible from the Issue itself unless we add this as a new label. I would suggest we move forward with priorities (since it can really help us identify what is important and what to work on next) through this GH project view and I can take action to update the project board accordingly. Let me know if this sounds like a viable path forward.

[mfisher87]

I think that sounds reasonable!

[asteiker]

@mfisher87 I'm sharing some notes from reviewing with @Sherwin-14 during our hackday:

• It looks like there is an erroneous "Unsupported markdown: list" box but I believe Sherwin needs some guidance from you on how to remove.
• There is a step to Remove "pending triage" label, but we don't have that label to begin with. I suggest we open a new Issue to add this label to all newly entered Issues. (side note: I'd love to contribute to this if it's not too technical. If you have any guidance I'd love to hear!) I wouldn't want this to hold up the PR but otherwise that step won't make a lot of sense before we have the "pending triage" label to begin with.
• Adding thoughts on priority levels in your comment above.
• I suggest we soften the language on issues that do not follow a template (the first "no" fork). I wouldn't want this to create a perceived barrier to contributing an issue if they are basically asked to redo what they wrote originally. I believe there may be cases where either a user does not understand the difference between issue templates or feel that their issue doesn't fully belong in one or the other. Could we instead say "Identify whether an existing template is appropriate and migrate the issue to that template on behalf of the issue reporter."

[mfisher87]

1. I have a comment above for this; we need to make the thing not-numbered. I believe Sherwin and I worked on this together in a hack week and made some progress. @Sherwin-14 is there a chance you have some un-pushed work?
2. Good idea. My original advice to Sherwin was to drop this step in the flowchart to keep it simple and aim to represent how we work now. But if we think we're ready to adopt that workflow, let's do it! I think it's not too technical :) To keep with our existing patterns, how about Needs: triage? I suggest implementing this in the issue templates. We already have this but it doesn't work because the label name in the template doesn't match any real labels:

   earthaccess/.github/ISSUE_TEMPLATE/bug.yml

   Line 7 in 74c0ef5

   - Needs Triage

   (the YAML will need to be quoted to add the colon or the colon will be interpreted as a key/value separator)
3. Responded above :)
4. Yes! Great call. Perhaps "request needed information from reporter and update issue on behalf of reporter"?

If we're seeing users struggling to figure out which template to use, maybe we could do more to guide them in our config?

[mfisher87]

@Sherwin-14 how are you feeling about the next steps for this PR?

[Sherwin-14]

@Sherwin-14 how are you feeling about the next steps for this PR?

I was waiting for the next hackday to start working on this again. I believe collaborating on this alongside @asteiker would be the ideal path forward. We can list all the areas where improvements are needed, in that way I would also get an idea about what steps I need to take moving forward. I had individual reviews from you and Amy, but I feel collaborating together on this coming hackday would make it easier to keep a track of suggestions and improvements.

[asteiker]

@Sherwin-14 Yes, let's finalize these open items together at the hackday. I would also like to start implementing the priority designation in the bug priority project view: https://github.com/orgs/nsidc/projects/10

[Sherwin-14]

@Sherwin-14 Yes, let's finalize these open items together at the hackday. I would also like to start implementing the priority designation in the bug priority project view: https://github.com/orgs/nsidc/projects/10

Hey Amy! Could you summarize the improvements that we agreed upon on the last hackday? I do remember some of those but I guess you have a better idea about this.