Suggestion: Short Q&A section ? about package-maintenance

[Eomm]

I totally agree when you say that is "hard" and if we facilitate the opt-in more people will join us to help.

Maybe could this section be filled with more info after this analysis phase will end and some "dirty jobs" will start?

[wentout]

@mhdawson @rxmarbles seems we've figured out with the solution for this issue on the last meeting 2019-03-11. We've discovered we can try to share focused vision throgh "Projects tab".

So I will close this, if you don't mind, may I?

[wentout]

... after this analysis phase ...

Ah, yes, sure, I mean this too. Might be I hurried with this suggestion.
Anyway it will be hard to answer this questions right now.
Though, it might someone will try to make assumptions, may be me.

[mhdawson]

My hope is that we will end up with a concrete list of "jobs" (dirty or not) that people can help out with but I think it will take us some time to figure out how to build and maintain that list. I think the idea in this issue: #131 is one where somebody with time could start digging in though. Key things from the discussion on 131 in the last meeting is that:

• It needs to be opt in(ie don't spam module owners with PRs unless they ask for them)
• Build a framework so that when we have change Y that is needed across the ecosystem we can use the framework to generate the required PRs
• We might be able to start with the buffer constructor problem. It may be partially addressed but not completely.
• For the buffer constructor problem it may not be fully automatable so maybe the tool would help to generate the initial version of the PR but then one of our volunteers would have to review/finalize and then submit to the package's repo.

[wentout]

No objections, closing.