added tips from Scott Hanselman

http://www.hanselman.com/blog/30TipsForSuccessfulCommunicationAsARemoteWorker.aspx

@RadValentin, great input.

I wasn't planning to accept pulls at first, since we could all have our forks that match particular flows/cultures. But in the end this is what open source is all about, collective input. And I didn't really advance with this either..

There are a few problems I have with your pull at the moment, though.

My first concern is simplicity, I wanted to point out concepts and meaningful insights, not particularities that will always differ between different human behaviors. In a way I'd like this guide to be a set of rules that allow people with different working habits to work together successfully (I.e. removing bureaucratic restrictions that dumb down people's creativity to their common denominator.)

I like that you split responsibilities into basic principles. Availability, communication, etc.

I'm on the fence with email. It has a lot of value if you use it correctly, and it's kinda of vital component. But it's still something specific, compared with, say, being available. Who knows, maybe there's an ace group of people somewhere, working remotely without the use of email. I'd still list core principles of email, since I rely on it, but maybe put it under Tools.

My biggest problem is with Tools (that's why I had difficulties filling this section in the first place.) If we're going to link to actual products, we should strive to promote open source/cross-platform/free(mium) solutions. Microsoft doesn't feel too right :)

But rather then saying you need Dropbox, for example, I'd say "File sharing/backup/etc." under which I might list it as an alternative. The Need should stand out and is more important than the commercial product. If there's anything I hate on the internet it's the "50 best tools for x" articles. Most people still don't know how to use email.

Having external links are also against the simplicity of these guide. We could add references to entire books if we're to go down this road, 37 Signals just published REMOTE for example, which I'm sure is an awesome reasource

@skidding Thanks for replying! I wasn't sure if you were willing to allow collaboration on this project and I'm glad that you're ok with it.

Ok so, I'm not going to pretend having vast knowledge of working remotely. Actually that's wrong, up until this point all of my jobs have been remote. The thing is as a web dev, especially a remote one my role has always been very insular as in client sends tasks in a bottle, time passes, I send results back in the bottle. This is not the case anymore, and lately I've been forced to evolve into a more active role within the "team" (I do lots of freelance so team has a really loose meaning). My goal for this guide was initially to add in bits of information that I've found vital in this transition process, that's the reason for the somewhat focus on communication.

The more I think about it, the more I agree with your desire for simplicity and a general focus on serving as many readers as possible. On the other hand I fear that this guide goes to abstract to the point it's not useful to anyone. Like those "50 best tools for x" articles you mentioned, the web is full of information on every imaginable subject but not very often does that information serve it's readers.

In regards to email, I agree with putting it under tools. Thing is, I wasn't sure if tools was meant to be an actual list of products or just a list of types of tools like "file sharing, backup, etc". Not putting actual products under tools kinda feels wrong because you run the risk of becoming too abstract. So I guess we could make it a list like this:

• file sharing : recommendation 1, recommendation 2
• backup: recommendation 1, recommendation 2
• etc

There should also be some kind of comment on how these are only recommendations and that each user has a responsibility of choosing the tools he's most comfortable with.

Yeah, about MS products, I'll remove Lync, it was a bit of a long shot on my part. Let's make a rule of only including tools that are actually useful to the writers, or at the very least to the people you work with. That being said if a tool is useful to anyone contributing to this project and he can make a good case for including it, then it should be considered even it's paid-for, made by MS or whatever.

Lastly about including external links I'm not sure if I agree. I believe that whatever you're writing about you should always list the works you've used when researching the subject. It's not only fair but it also shows the readers that you actually took the time to study up beforehand.

Ok, that's about it. I'm curious what you think about my thoughts above. In any case, I'll continue researching the subject and making the changes discussed in hopes of getting this request accepted.

Thanks!

A lot of ideas pop in my mind now, I'm very glad you initiated this conversation. We need to find a way to collaborate though; we both have good ideas and complementing knowledge. It's a vast subject, but managing to pull this off should confirm that we got the basics of remoting, so the validity of the project itself is at stake :)

It is obvious at this point that I won't be very available. I'll try to bounce back faster, but since the subject is high-level it's hard to digest on the go, it will still require a certain focus. Which brings me to the following suggestions, let's apply the knowledge we have from managing regular projects.

• You included several improvements in this pull, of various nature, let's split them into individual issues and iterate faster with clear scopes. Like "split availability and communication responsibilities into two big concepts with separate bullet-points" or "add tool categories with up to three product examples", etc. On some subjects we might agree very fast, while on others debate will continue (like the bottom resources links :P)
• We can branch out subjects in sub documents. I was thinking about the email use case. An email guide is very important, there are some key concepts to be outlined. But since we kinda agreed that it could be simply listed under Tools, next to versioning, backup, screen sharing, and whatnot, it could very much have a link to its own document within the Wiki, for people who want to immerse into that subject. This might make it easier to delegate efforts between potential contribuitors, and keep the main document an insightful easy-scan

What do you think?

(but seriously, we should really read REMOTE in the meantime, I think it's released)

Just wanted to give you some form of update, I've been silent for a while but I haven't abandoned the project, just been very busy. Did you get a change to read REMOTE? I'm curios to know what you thought of it and do you think there's still room for us to add something meaningful to that conversation?

Anyways, I've got more time on my hands now, and I plan resume work on writing this guide. Some time on Saturday I'll push the changes we talked about to my repo and we can start looking into how to expand the guide.