It would be very easy to contribute by writing documentation to most open source projects, they'd be happy to take it.
Coordinating teams and planning releases.... I think a lot of open source projects could _use_ help planning releases (release management is incredibly important), but I'm not sure they'd _take_ it from a stranger they didn't trust (and they might be right). "Coordinating teams" not as sure how it would even look or would be needed. But anything that looks like being a "boss", people are going to be resistant to, esp from a newcomer stranger, for obvious reasons.
But I bet people will welcome documentation contributions with little hesitation. For the rest... if you want to try, I recommend taking a product you're familiar with (as a user, not a developer), and offering your services being very careful to come from a real service perspective. Your job is to figure out what they need help with and how they want it done, and help them do it -- not to tell them what they ought to want to do or how they ought to want it to be done, not at first even to helpfully _suggest_ it. At least not until you've built up a lot of trust.
After writing documentation, I think the thing you mentioned people would be most welcome to and least resistant to would be 'triaging issues' -- but I think you'll have to build up some trust (say, by writing documentation!) before people will be willing to trust you with it.
Coordinating teams and planning releases.... I think a lot of open source projects could _use_ help planning releases (release management is incredibly important), but I'm not sure they'd _take_ it from a stranger they didn't trust (and they might be right). "Coordinating teams" not as sure how it would even look or would be needed. But anything that looks like being a "boss", people are going to be resistant to, esp from a newcomer stranger, for obvious reasons.
But I bet people will welcome documentation contributions with little hesitation. For the rest... if you want to try, I recommend taking a product you're familiar with (as a user, not a developer), and offering your services being very careful to come from a real service perspective. Your job is to figure out what they need help with and how they want it done, and help them do it -- not to tell them what they ought to want to do or how they ought to want it to be done, not at first even to helpfully _suggest_ it. At least not until you've built up a lot of trust.
After writing documentation, I think the thing you mentioned people would be most welcome to and least resistant to would be 'triaging issues' -- but I think you'll have to build up some trust (say, by writing documentation!) before people will be willing to trust you with it.