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?
As part of our current packet of work, we are also in the process of rehauling our tools’ ecosystem. There is a page we’re working on (still WIP, hence why it hasn’t been made public yet) where we have listed all the tools, their repos and whether they are deprecated, soon to be deprecated, supported by the team etc. As part of that work we’ll also label each repo correctly.
Hi @rossjones - sharing what I (think I) know…also keen to hear if someone else has more clarity
There are some community collaboration guidelines (I don’t know the current status - but only developed last month) which includes a section on github which I think works out to mean:
Members of the community should then get in touch (not sure how is best) with the Tech Team to say what bits of those areas they are keen to contribute on
If an agreement is reached that inputs are appreciated - community members should raise an issue first, and then the Tech Team will indicate whether they prefer to deal with it themselves - or for you to submit a PR (with tests)
Unsolicited PRs, or PRs on ‘active’ issues (things that the Tech Team are currently working on themselves) are not welcomed
This is probably not what you are used to on github!
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!
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:
The contribution guidelines […] should be updated to more accurately reflect the process, in order to manage expectations. Make an effort to respond to PRs (by adding labels on Github) to say if something is a priority and when it might be possible for it to be reviewed.
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.
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).
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.
Sorry for being slow getting back, I’ve reduced my paying work to spend a bit more time on OSS, but life intervened this week.
Thanks for all the feedback and info, it’s really great to see this discussed, lots of really good points and a more clarity for me. I particularly take the point about responding to pull-requests/bug-fixes/issues, I’m deeply aware of how much time these can take to respond to, and how frustrating it can be for both parties waiting for responses - and yes, it’s definitely worse if people randomly submit new features w/o discussion.
With a limited number of people working full-time on the repositories though, perhaps the issue is the number of people ‘allowed’ to respond/interact/merge changes? In the CKAN community we went from only OKF contributors to a technical team made up of people from many organisations - is this the case with IATI, or is it more a case of ‘an organisation working in the open’?
Apologies for the possibly naive questions, still trying to find my way around.
