roadmap

[rdallman]

currently, it's hard to get a feel for what's actively being worked on for external contributors / observers. we should at a minimum make what we're currently working on less of a mystery, not necessarily (read: not at all) trying to iron out the perfect workflow here.

Rough proposal w/ github issues:

• Keep a generic ROADMAP 'project' open https://github.com/fnproject/fn/projects which continuously updates
• we can automate almost all of this using the 'projects' column features
• the best roadmap is things actually being worked on currently and things on the immediate horizon (not who-knows-how-long out)
• project automation allows every new issue to get added to 'TODO' column, we can do that
• project automation allows every PR to get added to 'In Progress' column, we can do that too

shortcomings of ^ :

• columns do not allow sorting
• automation stuff has a limited number of capabilities, and the proposed isn't much different than 'issues' and 'pull requests' except in kanban form

alternatives:

• automation does allow us to add something if 're-opened' from another column. we could use this as the flow which would require closing every issue immediately only to be re-opened when actually getting worked on, then when re-opening the issue would pop back up in the WIP column. issue being it's hard to differentiate actually closed issues vs. closed but not done issues (could use labels, still meh)
• github allows linking to issues sorted by thumbs up - we can use this as our TODO roadmap, if we're diligent and lavish with thumbs
• i like the idea of a column of 'assigned to' issues being our WIP, but this doesn't seem tenable at the moment and the amount of effort to assign yourself + add to the WIP project -- it's directly below the 'assignees' part -- isn't very much (albeit, marginally, 100% more)
• maybe the answer is that PRs are enough for WIP, if we open stub PRs with WIP tag

while the github automation stuff is a bit limited, if we can stick to an automated process then we'll actually stick to it. if it's not automated, it will likely get abandoned -- thus, I think we should adapt to what's possible instead of trying to morph github projects into something it's not currently capable of. maybe somebody else has/had some thoughts on this or one of the above ideas sparks a better one. would like to keep it extremely minimal and automated and don't really want this convo to snow ball into a 'release cycle' discussion.