Quarterly project Roadmap update

[w7sst]

• Update the quarterly Roadmap before sending out the invite to prior authors.
• remove the Roadmap table. This was too difficult to maintain.

[w7sst]

Hi @scotthibbs ,
I thought we should update the Roadmap before sending the invite out to initial authors.

Please review, edit and approve. However, please hold off on performing the merge.

I want to try a different option when merging in this change. I notice that we are not getting a linear history with the merging technique we are using. Linear history means that each change occurs after the other on the main branch without extra branching/merging. You can see this our Insights | Network page. This page is pretty cool - try hovering over each "dot" to see the checkin comments. We may add a rule that the developer performs the merge, not the reviewers.

Thank you.
73, Mike

[w7sst]

Scott, I'm also wondering what you think of making direct changes to README.md without an associated Issue? I think MR-related changes should always have an Issue. However, these project related changes, especially the simple Community pages updates, may not always need an issue. The downside of this attitude is that we add a special case to the rule that all changes should have an associated Issue.

[scotthibbs]

I like it.

I agree we can make the readme.md change outside of an issue being created. Also we can make the readme.txt at every release or as needed without an issue. Since these do not involve coding.