Redo readme #32
Redo readme #32
Conversation
|
By the way you can see what this looks like on my fork: jasonrhodes/mentors … |
|
@jasonrhodes Nice work. I would like to suggest here as mentoring should be more of a one-to-one discussion it will be good not to bombard the |
|
@suroorwijdan great point, I think this should be a responsibility of the mentors to push those discussions off of gitter and into a more 1:1 format. This is something we should definitely watch for during this trial period. |
|
I thought the purpose of putting the additional info on the mentors list was so that mentees could use the listed methods to start a 1:1 conversation if they needed help? I listed my github and my twitter, both of which could be used to start a 1:1... A github issue can go unnoticed and unassigned, and the gitter is a lot more public than is appropriate for 1:1... I just don't know why more than contact info is needed, if the purpose is just to connect mentors to mentees. In reference to #28, we could build a small front end to enable mentees to search for a mentor near them, and just list their contact info. This is the kind of thing that I would utilize if I needed it, and something I definitely could have used when I was learning. |
|
@therebelrobot when you say "I just don't know why more than contact info is needed", what do you mean? More than a list of mentors on the README? The idea is to remove the burden from the person looking for help and instead let them outline what they need help with, and let mentors respond based on what they're comfortable/knowledgeable about, etc. |
|
@jasonrhodes I think giving adequate tools to find experts near you removes the burden enough to make it a viable option for assistance. Are you wanting to build a system that parses the issue and queues it to the mentor that can help best? Often mentors skills are fluid, not easily quantified enough for automatic queuing, Passive queuing is easy to ignore, and more often then not, reaching out to someone nearby to talk to face to face about your issues in your code can help break through to proper solutions. Of course if a particular mentor is not comfortable with the issue, he can refer them to another mentor he knows has a different skillset, but the initial contact needs to happen from the mentee no matter what method we end up going with. We could either allow that initial contact to be open ended (email, twitter, git, even gitter), or we can close the process a little more (type in your issue and it hits a queue to work on), but the more the process is closed, the more it feels like (to me at least) that those we are helping are just numbers, just issues to work through, not living breathing developers that need our time and attention. Just my two cents, but if I just have another list of issues in a queue somewhere, I'm going to find other things more pressing to work on. If someone emails or tweets me, there is a face, there is accountability, there is a sense of duty to assist. I could be alone in that thought. If so, maybe I need to find a different org to assist with mentoring. I thought that's what this org was for though, to give mentees points of contact for assistance. |
|
I just don't know how this setup is any different from stack overflow based on what you've described. In the PR, it states:
A queue of issues doesn't foster healthy mentoring relationships, direct individual conversations do, otherwise stack overflow would be perfect for what mentees need. |
|
@therebelrobot Thanks for your feedback. The current idea is that we ask people who are volunteering to mentor to do more than just list their contact information and wait to be contacted. We're asking those volunteers to spend a few minutes a day looking through gitter and the issue queue to see if anyone has requested mentoring, and to suggest 1:1 match ups based on comfort, language, knowledge, location, etc. This method removes the burden from the mentee. A person can just say, "I don't understand promises, can someone help?"—at which point the mentors would see this and someone comfortable explaining promises could initiate a 1:1 conversation with the person, going forward from there. This method may not work at all, but I think it's important to get something started, even if it's minimal, and then iterate on it. That's why I suggested we time-box whatever idea we choose to start with to a few months and then evaluate how it's working, suggest changes, etc. @nvcexploder: what are your thoughts based on the Hapi mentorship experience so far? @mikeal @hackygolucky are you leaning a certain way on this? |
|
@jasonrhodes that's fair. In that event, this org probably isn't a fit for me. I already have 3-4 different queues I sift through daily, including stack overflow, I don't see the need for another one. I'll just continue assisting from nodeschool. I'll add my pull request to remove my name from the list today. |
|
@therebelrobot I don't think there's any reason to remove your name, especially as we're still trying to figure out how this works! (If I had to guess, we'll end up with something that includes both directions of initiation.) Totally up to you, but I'd love to see you stay on the list and provide feedback about the process as we go, whenever you have time. |
|
@jasonrhodes Since I was so new to the group, I figured I misread the requirements somewhere. I know that if I as a mentor am going to be expected to read through issues, I'm not going to with everything that's on my plate professionally. If you're cool with having my name on there as a contact, and pick up individual conversations as they come in, that's cool, I'm happy to assist. Heck, I'll even schedule to meet in person if mentees need it. I just don't want to give the impression that I can do more than that. Adding a new queue to my workload is a huge thing, and most likely will get backburnered. No hard feelings at all, just trying to give the right info out about what I can do. |
|
@therebelrobot Sorry about the confusion, as this project is in very active development/planning. It was suggested that we throw up the MVP--being the README. The momentum of that alone was quite surprising to us and caught us off guard. As for sifting through issues, there is no intent for that to be a requirement for mentors. We intend to help encourage matching as project managers of the Mentors program. The matching mostly involves making sure the expectations of the mentors and mentees match up(time commitment, level of comfort in language, timezone located, spoken language, etc.). Your insight is super helpful. It helps us understand what people are assuming this project does and doesn't do. Thanks for your support and encouragement, regardless of whether you continue with the project. |
|
@hackygolucky No worries. I'll kill the PR for now. I just want to make sure I can commit to what you guys decide to do. I'll go lurker for the time being. |
|
|
||
| 2. Ask a question on [our Gitter channel](https://gitter.im/node-forward/mentors) --a chat room that uses your GitHub login as your user account. We'll be watching that channel and responding there, hoping to pair up as we find good matches. | ||
|
|
||
| 3. `<less public method tbd>` coming soon... |
There was a problem hiding this comment.
I'd like to make the form 1. in this list. It does make more work, but I'd like to make sure mentees know there's no shame in private submission. It also allows us to capture the most information about how we can help.
Sent you the form draft as well!
There was a problem hiding this comment.
Maybe we just push everyone to the form and forget the issue queue? It seems confusing to offer the issue queue option if what we really want is the form submission, and then it really destigmatizes private submissions....
|
OK @hackygolucky and others, I made a few changes re: what we've been talking about with pushing everyone (mentors and mentees) through the Google form. We'll just need to add the link in two places with another PR or I can add to this one, w/e. |
|
And here's the link to see this on my branch: |
|
Also, see #49 for why I removed the "submit a PR" advice for now... |
…geset if we're going to move to google docs
|
OK (sorry for having a conversation with myself here) but I put the "submit a pull request to add yourself to the README) back in for now because we have #49 to discuss, so if we decide to move the list to Google Docs we can change the README then to reflect that. Once we get the form links in there, I think this is ready to go. |
|
Haven't been at my computer today but I'll try to do that this evening! On Sat, Nov 22, 2014, 2:55 PM Jason Rhodes [email protected] wrote:
|
|
@jasonrhodes I think the form is in a good place for us to drop in the url. It's at https://docs.google.com/forms/d/12OC7RgjoBvypP1HA2yBVgG31OdCSRbW4sXHMaZec0Jo/viewform?usp=send_form or I can make a new branch with your changes AND mine. |
|
I'll add the link to my branch in the morning and then merge it all in. thanks!
|
|
I noticed the timezone field is being validated as an email field and the code of conduct link isn't active. There also doesn't seem to be an explicit option to sign up as a mentor or mentee which may be intended. I like the idea of a mentor mentee scenario being a learning opportunity for both parties. I'm excited to see this initiative progress! 😄 |
|
@hackygolucky |
|
Folks, how about generating a website with @jlord's sheetsee.js from the Google Spreadsheet data? |
|
+1 |
|
@LegitTalon and @hemanth good catches. I've made a few updates, @hackygolucky. @mcollina can you suggest that in a separate issue and reference #49 too? That way we keep things separate and focused, thanks! I'm going to merge this request as soon as I push the form link addition. |
|
FYI until we get that Code of Conduct up at that URL, I made that question "not required" and added "(coming soon)" to try to avoid confusion for now. We'll get those back in place as soon as the CoC is up, but for now I figure we're no worse than we were when we just accepted PRs of people's names. |
Starting the work I mentioned in #26