Meeting happened not clear
Closed this issue · 7 comments
I think the way to set the meetings as "concluded" or that they happened isn't clear. I suggest the community have a conversation on how to improve this feature.
We had some discussion on issue #59. I like the idea of the feature, that's why we had it for a while but as I used the platform it quickly became apparent that "it's too much to ask" for users. At that point the process required.
- Reserving a meeting
- Confirming the meeting
- Cancel if it was needed
- Answering if the meeting happened or not
That last step is a bit more complicated than it seems. Who should answer that question, the mentor, the protege or both? What happens if they disagree?
On top of that the only value of that action is to have better stats on the site's usage and there's not much of an incentive to users. Maybe if we can come up with a points, credits, achievement system.
Would really like to hear what other people think about it.
Sports analogy so bear with me:
In some sports you win, you lose, or you tie. This could be used for the meeting confirmation. Both protege and mentor answer, if both answers are different that meeting can be marked as a conflict, if both answer as canceled/did not occur or completed/did occur then the meeting is marked accordingly. With this you can tally up a mentors and proteges "score" or rating.
I think something like this would stop people from trying to game the system. When rep is at stake one tends to behave accordingly.
Meeting Flow:
- A protege requests a meeting with a mentor
- The mentor confirms the meeting
- With protege or the mentor can cancel the meeting (is that right, as a
protege I've not tried to cancel a confirmed meeting) - Then, IMHO, it should be the protege who has the task of closing the
loop and declaring that the meeting happened or cancelling.
Perhaps, after the time/date of the meeting has transpired, the mentor can
no longer cancel. I know that puts a lot of the burden on the protege, but
isn't the system ultimately for the proteges?
That leaves the potential mess, if meetings happen and the protege does not
either cancel or close (mark as happened) the meeting. Or the uglier mess
that the meeting actually happened, and the protege cancels it.
This is where the history starts to become a critical piece of the system,
maybe there are some tweaks possible in the history that can illustrate
the messes caused by the user, i.e., not cancelling meetings or marking
them as closed. Or even assign reputation points for correctly following
the desired system flow. Surely, there is more value to closing the loop,
than merely as a statistic.
On Sun, May 18, 2014 at 9:14 PM, Froilan Irizarry
notifications@github.comwrote:
Sports analogy so bear with me:
In some sports you win, you lose, or you tie. This could be used for the
meeting confirmation. Both protege and mentor answer, if both answers are
different that meeting can be marked as a conflict, if both answer as
canceled/did not occur or completed/did occur then the meeting is marked
accordingly. With this you can tally up a mentors and proteges "score" or
rating.I think something like this would stop people from trying to game the
system. When rep is at stake one tends to behave accordingly.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-43459510
.
Kevin Shockey
President
Puerto Rico Python Interest Group http://www.prpig.org
Mis Tribus http://blog.mistribus.com/
Twitter Feed: @shockeyk http://www.twitter.com/shockeyk
@mistribus I completely agree on placing the burden on the protege for now. The tradeoff is completely fair, but a rating / reputation system is unavoidable in the future. Time is the currency being dealt in this platform, so this would repel any time-thug / looter.
Having history all of the actions / events could definitely be of great aid to further streamline the meeting process. Along the points @froi and @mistribus mentioned, benefits of crunching this data into a simple no-bs, rating system would include:
- Reduced friction between the two parties involved.
- Guarantee to any future proteges / mentors of their time about to be given away.
- Less frowns 😄
So where are we at with this?
On Mon, May 19, 2014 at 7:16 PM, Jonah Ruiz notifications@github.comwrote:
@mistribus https://github.com/mistribus I completely agree on placing
the burden on the protege for now. The tradeoff is completely fair, but a
rating / reputation system is unavoidable in the future. Time is the
currency being dealt in this platform, so this would repel any time-thug /
looter.Having history all of the actions / events could definitely be of great
aid to further streamline the meeting process. Along the points @froihttps://github.com/froiand
@mistribus https://github.com/mistribus mentioned, benefits of
crunching this data into a simple no-bs, rating system would include:
- Reduced friction between the two parties involved.
- Guarantee to any future proteges / mentors of their time about to be
given away.- Less frowns [image: 😄]
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-43570031
.
Kevin Shockey
President
Puerto Rico Python Interest Group http://www.prpig.org
Mis Tribus http://blog.mistribus.com/
Twitter Feed: @shockeyk http://www.twitter.com/shockeyk
Maybe tonight I can find some time to make a few mockups to share and test the idea. My biggest doubt is related to actually making people answer if the meeting happened.
@gcollazo How about:
A. A follow-up email (with the direct link to confirm) as soon as the meeting date is over.
or
B. The next time the user logs back into 1hr, show a notification or a link so he can take care of it.