Hi!
I’ve been trawling through the github code repositories for small issues that I might be able to contribute fixes to. The problem I’m facing is that it isn’t clear which repositories are active and which are not. For example, I was looking at issues in https://github.com/IATI/pyIATI and it was only through looking for further information/context that I noticed that it appears to be inactive. Then I was looking at IATI/IATI-Datastore and it took some effort to realise that it is being re-built.
Would it be possible to mark those repositories that are no longer used as either unmaintained, archive in github or add to the readme where appropriate marking it as deprecated?
Thanks
Ross
rossjones:
Yep!
Via GitHub: keen developers can refer to all of our repositories and start contributing, either by fixing open issues or by raising new ones. This can happen on tools we’re focussing on for the quarter as well as those we’re just keeping on the backburner.
Yes and no: this is completely true for new feature requests that significantly alter some tool’s current functionality (example, made extreme on purpose: “Remove the forward looking calculations from the Dashboard and change its methodology”) or for enhancement/bug fixes that aren’t too trivial.
It’s essentially the normal triaging process any dev team foregoes internally, except for us (where us is me, John and essentially all of you contributors!) it’s going to be an asyncronous exercise!
Yes and no: they are most certaintly welcomed and considered, just we might be working and focussing on other things so we might not get to them straight away. What we were trying to prevent with the guidelines are reminders that certain PRs/issues have been open for X amount of time. We’re a team of two at the moment, time and capacity don’t always allow for instant interaction with non-priority work. What we want to try is to at least get to comment to an issue or give it a thumbs up as a way to let the user know we have seen it and added it to our backlog!
Essentially, in a shorter version: we do encourage and welcome open and spontaneous contributions to our codebase, there are no restrictions to who can suggest/fix/raise what, always bearing in mind that we do have priorities and can’t always get straight to your issues, but we will eventually!
Thanks Matt for these bullet points, it was a good breakdown and useful to help clarify some of those aspects as well!
Thanks so much for taking the time to set this out Samuele Mattiuzzo - much appreciated
+1, a comment, or some acknowledgement (a thumbs up) on issues or PRs would be a really good step forward.
A good combination that would put minimal demands on the tech team but give useful feedback to the contributor would be a combination of a like (“we’ve seen this”) and adding a label like WontDo, Later, Soon, Priority, etc (“here’s how we plan to respond”) and/or a milestone.
This would be great. In fact agreement to this effect was reached at last year’s technical audit in The Hague. The following is from the writeup:
Whether it’s great minds thinking alike or fools seldom differing, I’m glad we’re all thinking among the same lines.
This has already happened and keeps happening many times, so the step forward has already been made.
I’m torn on this, not because I fail to see the usefulness of those labels, but mostly because they started growing too much in size, so we decided to use the labels that would benefit our internal day-to-day life.
Again, we’re flexible in how we deal with this, but essentially any activity whatsoever on your issue means the issue has been acknowledged.
If the issue is critical/breaking, there will surely be activity (either a discussion, status/labels updates or the code moves forward etc).
Again, I welcome this initiative to acknowledge issues and pull requests.
However, there are a number of cases where it hasn’t happened yet. In the spirit of community cohesion, I’ll follow up with you and Wendy directly about this, so it can be addressed.
Is “community cohesion” a euphemism for community policing?
More community engagement/enthusiasm, I’d think. As I’ve suggested before, having hundreds of enthusiastic people who are willing to fly around the world to debate arcane points of aid transparency or technology can sometimes be a challenge for staff to manage, but it’s also an asset of incalculable value.
Thanks for the reply. I understand that problem well, having contributed to label inflation myself on more than one tech project. I think GitHub labels aren’t a great tool for fine-grained workflow tracking – that’s why one ends up with dozens of long labels that still don’t do the job – but they’re great for a very coarse-level classification.
We don’t want to get into a situation where the dev team needs to divert signficant time to acknowledging each issue – that would be unfair to everyone, and would delay important work – but it would be good to be as transparent as possible (“Transparency” is part of our name ) within the bounds of, say, a 2-minute response-time budget.
“Yes, we’ve seen this” (like) is better than nothing, but “Yes, we’ve seen this, and our first triage pass is to work on it now / soon / someday / maybe / never” (like and label or milestone) would give a lot more feedback to the contributors with very little extra effort from the team (I hope).
that is quite a lot of time budgeted
Triaging an issue isn’t very little extra effort. So, instead of commenting with things such as “we’ll look into it someday”, I’d rather give a +1/thumbsup acknowledgement.
Then, once we get to it, you’ll be automatically notified by GitHub.
The only label I could add is an acknowledgement one, which isn’t any different than the thumbsup emoji. Milestones are also not viable, as it’s not their purpose.
GitHub doesn’t send notifications for reactions (e.g. thumbs up). So a comment is preferable.