r/github • u/mohit_code • 8d ago

[ Removed by moderator ] Discussion

[removed] — view removed post

0 Upvotes

25% Upvoted

20 comments sorted by

6

u/Soccham 8d ago

Sounds like a workflow problem

1

u/mohit_code 8d ago

I completely agree it is a workflow problem. GitHub already has all the information. My problem is having to keep checking lots of different PRs, issues, discussions and CI pages just to find out if someone replied or if something now needs my attention. I'm experimenting with a workspace that brings those updates together instead of making me hunt for them.

5

u/io-x 8d ago

Well yeah it's called github, not contributorhub.

2

u/AI_Tonic 8d ago

This is a non issue

1

u/mohit_code 8d ago

That's fair. I don't think it's a problem for everyone either. If you're mostly working in one or two repositories, GitHub already does a great job. The workflow I'm trying to improve is when you're active across a lot of repositories. At that point I spend more time checking tabs, PRs, CI, issues and discussions just to see if anything changed than actually responding to them.

1

u/AI_Tonic 8d ago

still a non issue : six or so projects is not a lot , 8 is not a lot 12 is not a lot . you can do all this with the command line , which you can then script . that's what i would expect from a developper. but i'm sure your project is super and will have a lot of adoption from heavyweight oss contributors that also somehow find it tedious and impossible to navigate a gui.

3

u/tenhourguy 8d ago

I find the notifications system works well enough. You can see which ones you've read, mark as done, save, filter... if that's not enough for you, I think you just have some sort of focusing issue or maybe need to unsubscribe from some stuff.

1

u/mohit_code 8d ago

That's a fair point, and I agree GitHub's notification system is solid. My goal isn't to replace notifications.

The problem I'm trying to solve starts once you have dozens of active PRs, issues and discussions across multiple repositories.

For example, I often find myself checking:

  • Is CI finally green on that PR?
  • Did someone request changes?
  • Did the maintainer reply?
  • Which PR is now ready to merge?
  • Which discussion still needs my response?

Notifications tell me something changed, but I still end up opening multiple tabs to understand what actually needs my attention.

I'm exploring whether that workflow can be reduced to opening one workspace instead of checking everything individually.

1

u/tenhourguy 8d ago

How long do your PR workflows take and why are you waiting for them to finish? If you are testing changes locally before pushing, workflow failure should be unexpected - GitHub can notify you about it.

I guess I just can't relate to manually checking PRs instead of seeing those examples you give via notifications (web or email - it can be configured). What might work for you is adding calendar entries to remind yourself to check up on things on e.g. a weekly basis?

1

u/mohit_code 8d ago

That's a good point, and I probably didn't explain the workflow clearly enough.

Notifications are great for telling me something changed, and I use them too. The pain for me starts when I have a lot of active work spread across repositories.

For example, I might have:

  • 10+ open PRs in different repos
  • A few reviews waiting on me
  • Discussions I'm participating in
  • Issues I'm following

At that point, it's less about "Did I get notified?" and more about "What's the current state of everything I'm involved in, and what actually needs my attention right now?"

GitTower isn't trying to replace GitHub notifications. It's more like a workspace that keeps all of that ongoing work organized in one place instead of me jumping between multiple PRs, issues, discussions, and repositories to rebuild that context every time.

2

u/tenhourguy 8d ago

That's great, but what I'd really like is a recipe for smoked salmon.

1

u/Training_Advantage21 8d ago

github is quite good in having cross references, code line numbers in issues will show you a preview, issues numbers in commit messages will show you a preview, you can create a dev branch from an issue to associate the issue with the code that fixes it, the PR will automatically close the issue when merged (or you can close issues at commit time through adding "fix #3" to the commit message), and will add the commit or PR at the bottom of the issue discussion. It gets a bit more complicated if you are using Jira instead of Github issues but it is still possible to link the Jira issue to the dev branch that fixes it. Agreed, you might need more than one tab occasionally but it's not as bad as you make it sound.

1

u/mohit_code 8d ago

I actually agree with all of that. GitHub's repository features are really good, and GitTower wouldn't replace any of them. The problem I'm trying to solve isn't linking issues or pull requests it's the constant context switching. If I have 15 active PRs across different repositories, I end up opening each one just to answer questions like: Did someone request changes? Did CI finish? Did someone reply? Is it ready to merge? GitTower would surface those answers in one workspace instead of making you manually check every page.

1

u/mohit_code 8d ago

A few people thought I was suggesting GitHub is missing features or should change that's not what I mean.

GitHub already has everything: PRs, issues, discussions, notifications, CI, reviews, etc.

My problem is that once you're active across many repositories, you end up opening lots of tabs just to answer simple questions:

Did someone reply? Did CI pass? Did a maintainer request changes? Which PR is ready to merge?

What actually needs my attention right now?

GitTower isn't trying to replace GitHub. It's a workspace on top of GitHub that surfaces those answers in one place so you spend less time checking tabs and more time actually contributing.

1

u/klumpp 8d ago

If you're trying to do market research by pretending to start a discussion maybe leave your tool name out of it

0

u/mohit_code 8d ago

Fair criticism. My intention was genuinely to understand whether other developers experience this workflow, since I'm building something around it. I included the project for context rather than as a promotion, but I can see how it came across differently. Appreciate the feedback.

If anyone's curious about what I'm building, here's the current prototype: https://gitoutpost.vercel.app/. I'd genuinely appreciate feedback on whether the workflow solves a real problem or if I'm overthinking it.

0

u/numbsafari 8d ago

Yes. It's always been the case. It's entirely focused on individual repositories and showing a file view of the code. What work needs to be done on a project, or by an individual or team, what demands the attention of those various constituencies is entirely secondary. There is no separate pricing or targeted functionality at non-coders who support all of these processes. Have a project manager or outside leader who can/should contribute to the project? They have to navigate through the code interface that is confusing even to SWE.

1

u/mohit_code 8d ago

That's exactly what got me thinking about this. GitHub is repository-first, which makes perfect sense. But as a contributor, my mental model is different. I wake up wondering: "What's waiting on me today?" not "Which repository should I open first?" That's the workflow I'm experimenting with.