How do we coordinate work among Vulcan contributors?

[ErikDakoda]

I might have time to implement Migrate cache to Apollo v3 at some point soon, but if I do start on it, how do I make sure that no-one else is doing the same work?

I suppose I could set myself as an Assignee to that Issue, but is it common practice among contributors to looks through Issues to see if someone else is already tackling something they are about to embark on? I have not been in the habit of doing that, or opening an issue when I do start on something Vulcan related. Perhaps this is something we should agree on and communicate with the Vulcan contributor community.

We could also make it more explicit by using the "in progress" label for Issues that someone is already working on.

The one thing preventing the efficient use of Issues and PRs to coordinate among ourselves is that there are so many stale PRs, and especially stale Issues (178 currently) open. This makes it impractical to look through them to see if someone else is already working on a feature. Maybe it's time for a bit of housecleaning - closing stale and old Issues.

I see that we have a .github/stale.yml file in the codebase (though daysUntilStale of 60 and daysUntilClose: 7 is perhaps a bit too draconian - I would make it 180 days and 30 days). But the Stale action is not activated by a .github/workflows/stale.yml file. Maybe we should activate it.

I am interested in hearing your feedback on this @eric-burel and @SachaG or if there is already a system for this, please point me in the right direction. Thanks, guys!

[eric-burel]

Hi,

I think for the Slack is a good place to tell people if you are going to do something, as we check it often, so you can check that there is no duplicate effort. And then you can use a ticket to track progress.

At the moment, there is no strong leadership on Vulcan Meteor from either Sacha or me, as we are both busy and I am way more focused on Next.js. So I think you can do changes you think relevant quite freely.

Regarding Stalebot... I don't often have strong opinions, but I am really against this. Vulcan is a innovative project, classified as research and development in my company. It's also very dependent on 3rd party technologies, as it is a collection of preexisting libraries plugged togheter. And then, we are an active but very small community as you know it.

So, it makes total sense that a ticket is left open even years, because the underlying issue is difficult, because we wait for lib A to release version Y, or simply because we have a good idea but need more people to work on it.
This is a bit less true for pull requests, because they really go stale quickly, but they can also be useful as the first attempt at solving a ticket, so I am not eager to close them automatically either.

There are definitely stale issues though, I just mean that they need to be handled manually.
In 2019 I got help from interns so I managed to close many tickets and do a triage. But sadly in 2020 there has been less project offers because of the covid mess, so issues are starting to accumulate. So yeah, it's about time we clean them, but it will take some time to catch up.