Toshon Jennings, 8/30/2025

As I work on revolutionizing the way I use GitHub, I have expanded into Projects so that I don't have to follow all of my planning using my Journal, which is where I'd really like to put short term "To Do" items to help keep me on track throughout the day.

I'm sitting here, staring at GitHub Projects' date filter options: "Past 7 days," "Past 30 days," "Past year." Past, past, past.

But what about NEXT week? What about a deadlines breathing down my neck tomorrow, or the deliverables due this Friday? Apparently, GitHub thinks I only care about work I've already missed.

This is poor design, full stop. Not just an oversight—it's a fundamental misunderstanding of how humans plan work. Every single project management tool from Trello to Notion to a paper calendar understands that people need to see what's coming, not just what's gone. The exclusion of forward-looking date filters in a tool designed for project planning is genuinely astonishing.

Am I just missing something? Somebody help me, please.

Look, I get it. GitHub Projects emerged from software development workflows where sprints and milestones rule. Devs think in two-week cycles, not rolling seven-day windows. But GitHub's own documentation talks about Projects being "adaptable" and "flexible" for any workflow. How flexible is a calendar that only looks backward?

The platform does certain things brilliantly—the integration with issues and PRs, the automation capabilities, the multiple view types. Credit where it's due. But building a project management tool that can filter "Past 7 days" but not "Next 7 days" is like building a car with a rearview mirror but no windshield.

I'll max out what GitHub Projects can do, because I'm stubborn like that. But if I'm forced to manually tag items with "This Week" like it's 1995, I'll be forced to build something better. At least I'd include the revolutionary feature of... looking at tomorrow.

I've submitted this for discussion and review here.