Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the point previous user is making or I would add is: it is essentially up to you to decide what to keep and what not.

Simple example: say a comment points out some issue with the changes (say, lack of unit test on feature a), author could say that emulating scroll events in unit tests is complex and the mocks provide no real value to actual in-browser behavior.

This comment is something you may want to remove for the final merge or add a TODO: in the code, or leave the comments as a discussion for future but meanwhile push so prod people can test, etc.

You could move these comments to your saas git provider tools (e.g. github issues or comments or wiki for the final merge).

In any case the thing I like about this approach is that essentially *forces* users to actually checkout the damn thing and go through its code. I think this is something I would really want to test out with my team. I have a junior coming soon to my team (it's his first project and employment ever, he's 18), and I will test this approach with him and see how it works before I propose it to some of my peers and seniors.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: