A method to evaluate member experience

[chathuraa]

There are members with different levels of experience and skill set. We need a way to evaluate each members and make recommendation on mentor session. we can further enhance by incorporating availability as well.

[serkandurusoy]

Let's not evaluate. We can let everyone self assess around a few basic meteor experience metrics and allow them to update that information in their profile.

[chathuraa]

Maybe i didn't use the correct term, just thinking out loud, one might not know exactly where they are at compared to several different sessions happening. there is no way of restricting a beginner joining a expert class/session and that might not be a good experience for the others in a class...

[serkandurusoy]

Right, so what do you propose?

[henryswan]

I think it will be simpler letting everyone state their capability. We can include capability levels and the criteria/experience level to match each capability level, Then we allow users choose their level. Maybe that can be done in their profile too.

[serkandurusoy]

Yep, @henryswan that's what I had in mind but if @chathuraa or other members of the group can come up with other ideas, it would be great.

Remember, this is a learning experience, therefore our features should involve some tricky problems to solve ;)

[chathuraa]

Well, beginner, intermediate and expert are way too vague. what I refer to has "intermediate" might not the same on some one else's eyes. thats why i think we should have a solid measure, which will intern give a better learner experience. Im not saying we must, just throwing some ideas out.

[serkandurusoy]

I do agree that self assessment can always be skewed, but to allow for a better experience, we need to define our measurement metrics. So can you propose something?

[henryswan]

@chathuraa's suggestions may imply handing out some quick test to prospective mentees to ascertain their true levels.

[sakulstra]

Perhaps we are over thinking this. I think the coming mentor sessions wont be about some code questions, but about sentiments to different topics like yesterday - and there the skill level plays a smallish role. We had a rocket scientist, an economist, an informatics scientist, ... and it was just fine.

I wouldn't identify myself as a beginner, intermediate or expert. I'm definitely intermediate or even expert in some topics but a total noob in others. :) I've build some complex apps with blaze, but never used redux or react yet, so i'm still a total beginner there. For real "beginner" code-question we already have the meteor forums and irc and more complex questions are interesting for everyone regardless of skill level. Just as an example, I never intend to build a chat or banking application, but the answers about streaming and transactions yesterday where eye opening and probably help me somewhere else.

What I'm trying to say is "If it's nor broken don't fix it.". Just wait at least one or two more sessions and see how it evolves. I think the coming (problem) isn't the users ability, but where the user is interested in. So clustering on topics could be a solution.

Regards, Lukas

[ecerroni]

I agree with both @chathuraa and @sakulstra.

However when it will be time for coding we are going to face some challenges in terms of timing and code quality. As @sakulstra said someone can be good at something and a total beginner on something else.

Therefore this is a meteor-mentor crew and not a professional development team so what @serkandurusoy said still stays true.

I think this is the first real challenge we are going to face. The app outlined above makes sense to me. I like it. But that's more of a "technical" thing to me.

Here we must deal with user expectations and assumptions that can make it or break it for this app. That comes way before UI/UX imho.

So how can we find the product/market fit for this app? The good news is that actually we are the customers(!), so we should be able to solve this internally.

[serkandurusoy]

This is a great discussion. In fact this is a great practice for software development in general, start off with properly identifying the requirements beause often times the clients themselves will not be able to do that so we need to be fully aware of the problem domain.

Let's keep this going.

Few pointers that I'd like you to keep in mind:

• This is after all a learning experience so our features should cover different technical aspects, but not be overly complicated, let's think of this like something between an MVP and a 1.0
• I think highly experienced developers won't be using this platform for learning, and total beginners may be intimidated by it, so assuming there will be a "natural selection" around moderately experienced devs who have had a chance to play with it, go over the tutorials, perhaps spend at least a few weeks with meteor
• It is true though we would not want to span a too wide experience level because the beginners would be scared off while the experienced ones may dominate with quick solutions such that the class in general don't get the necessary time to think about and solve problems
• I want us to make mistakes and take the time to learn from those mistakes. Start with moderately good code and evolve it to good code in iterations.

[ecerroni]

I don't know if I can put myself in the "moderately experienced devs" category.

However as a "customer" of this future platform who is not a total noob here there are my desired outcomes. Outcome are a translation into measurable statements of my assumptions and expectations.

Desired Outcome* => Direction of Improvement (minimize/increase) + Unit of Measure (number, time, frequency, likelihood) + Outcome Statement

*That is taken from the JobstoBeDone concept and "What Customers Want" book

In no particular order:

1. Minimize the time it takes to learn new things about meteor
2. Minimize the time it takes to improve my coding skills in general
3. Increase the likelihood to produce good and clean code with Meteor
4. Increase the number of tools I can master (i.e. git, webpack, etc.)
5. Increase the likelihood to have slightly better peers in my group and the perfect mentor at my stage of skills (here I already feel lucky) :)
6. Increase the number of aspects I can handle with meteor
7. Increase the frequency of interacting with other coders
8. Minimize the number of headaches while deploying meteor apps
9. Increase the number of best practices I can follow about Meteor

[bearcanrun]

This sounds like it could just be a glorified todo/checklist app. Listing categories/sub categories of different aspects of Meteor development with check boxes for each item on comfort level (none, low, high) that can be used for both self and mentor assessment. Paired with goals, a member can compare the direction given by a mentor and figure out a plan of improvement to focus on. It's all self-assessment, so when you feel comfortable in something, just upgrade it yourself and move on to the next thing.

[serkandurusoy]

I think I kind of agree with this.