3 ms·

That's true, but the same respect-for-others is valuable in the other direction. Over time, the number of people who are _willing_ to learn your conventions, v

by gknoy 10y ago

That's true, but the same respect-for-others is valuable in the other direction. Over time, the number of people who are _willing_ to learn your conventions, versus those who _want_ t o use those conventions, may change. You may have several colleagues (and many more who have not yet contributed) who are willing to use email, but would prefer a web-based collaboration platform. Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail. Rejecting those out of hand as "not productive" seems a bit strange.

zeveb 10y ago
> That's true, but the same respect-for-others is valuable in the other direction. Very true! And certainly not all change is bad, and not all new things are worse than their older analogues. > Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail. True enough, but I wonder how much of that is not because they are fundamentally better but because email has gotten popular. I can't easily review source code via email because I have to wade through meeting invites, corporate communications and recruiter spam. Honestly, though, GitHub doesn't really give me a whole lot, other than centralised issue tracking and a data store. I never use its git UI; I just use Magit locally. I've actually been thinking about how a team could use commands to manipulate text files in a git repo to manage history for that repo — then one would never need to leave one's editor to manage issues. With a central file server open to users, merges and PRs could just be operations on the repo itself. My idea's not fully fleshed out, but I think it'd be awesome, and more productive that using GitHub via a web browser.

by gknoy 10y ago

zeveb 10y ago

> That's true, but the same respect-for-others is valuable in the other direction. Very true! And certainly not all change is bad, and not all new things are worse than their older analogues. > Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail. True enough, but I wonder how much of that is not because they are fundamentally better but because email has gotten popular. I can't easily review source code via email because I have to wade through meeting invites, corporate communications and recruiter spam. Honestly, though, GitHub doesn't really give me a whole lot, other than centralised issue tracking and a data store. I never use its git UI; I just use Magit locally. I've actually been thinking about how a team could use commands to manipulate text files in a git repo to manage history for that repo — then one would never need to leave one's editor to manage issues. With a central file server open to users, merges and PRs could just be operations on the repo itself. My idea's not fully fleshed out, but I think it'd be awesome, and more productive that using GitHub via a web browser.