Does it only work on PRs, or does it look at git history as well? Do you have plans to expand the knowledge it has access to?
- Most teams that I'd sell to use Github PRs to write code.
- Looking at PRs, the "common unit of change" of most teams, lets Devlog work for teams regardless of how they end up merging in changes (merge commits vs squash vs rebase... doesn't matter because the PR is what is reviewed and submitted)
- I believe that part of being a great engineer is learning how to describe (a) what your code does, (b) why you're making the change, and the PR title+description is where we as an industry expect you to communicate this information.
- A commit history filled with great PR titles+descriptions is extremely valuable for your team and only becomes more valuable over time, so building tools that analyze this and incentivize you to do a better job of writing good titles+descriptions is good for your whole team.
I'm extremely open to looking at different sources of information (Linear/Jira/Github tickets; the diff itself; ???) if it improves the product. What were you thinking it should look at?
Another reason I would want git history included is because I think it would make your product more valuable quicker. I see your tool as a way to improve the dev culture by promoting the points you mentioned, but it's not clear how long it takes it to start to pay off and be able to answer some of the more historical questions you've suggested. I question, if my team had poor/nonexistent PRs in the past, when would I be able to get any use out of it, and would there always be blindspots around code that didn't have a good PR.
> I question, if my team had poor/nonexistent PRs in the past, when would I be able to get any use out of it, and would there always be blindspots around code that didn't have a good PR.
This is a great question and the answer is that with poor/nonexistent PRs and documentation, Devlog cannot help you other than by incentivizing you to do a better job so that it can be useful — so not that helpful. I'd love to find a way to make it better in this kind of "cold start" case, that's part of why I appreciate your feedback about other potential uses. Thank you again.
It would be nice to know more about how I would interface with your product. It's not clear if it's a daily report, if it's a text box where I ask "What did Intern #3 work on last week?", if it's a chronological page, or something else.
Do different people get different answers? Would a CEO get a different answer than an engineer if they asked what the devops team worked on? Basically do you offer different levels of granularity for different user profiles.
Love the project and looking forward to watching it grow!