Brainstorming ideas for Front End and structure of the project

[TG1999]

Points finalized for now
1)Login Signup form for org maintainers.
2)Dashboard with the name of the contributors and color of their badge and also the following details written above in the idea.
3)A notification board (a link will be provided on the dashboard) that will update every week and will save the contributor’s name whose badge is faded.
4)The name selected from the notification board will open an email dashboard panel where admin can select the predefined email template for asking the contributor. We can use MailChimp to create email templates which can be later on exported as HTML and CSS for further use in our app.
5)We can have cards dedicated to each contributor. Upon clicking on the card, further details like their contribution history and period of inactivity (leading to fading of cards) will appear.

[sarthak77]

History of badges as in at what point the badge changed.
Many on the channel thought it to be a good point

[TG1999]

@sarthak77 Please can you describe this idea in detail as it was discussed on the channel it will be a great help for others.

[atharva3010]

Suggestions for point number 4:

We can use MailChimp to create email templates which can be later on exported as HTML and CSS for further use in our app.

[sarthak77]

For history of badges:
Make a card for each contributor. Then, on clicking the card, his whole contributions will be shown and period of inactivity, which leads to fading of badges
This will be similar to a person's rating like in coding sites

[sarthak77]

Can we have a notification system in which a person who is not active for very long time receives a notification and if the person posts after a long time then admin gets a notification that 'X posted for the first time in a while'

[TG1999]

@sarthak77 thanks for the idea, but since this is project is only for maintainers to look inside the community not for the contributors so notification system for in activeness won't work. And for second idea of 'X posted for the first time in a while' lets look the response of the community .

[jaskiratsingh2000]

@sarthak77 I am not sure about 4th point that we should really go for it or not, because sending emails to contributor ( who maybe don't want to contribute any more) can be a spam, so it should be like notifying on the same admin dashboard about contributors added, disappeared. Maybe it can be like a survey analysis on the board it self.

And do you have any ideas that once I shared like adding integration, for instance adding user to some trello board , etc try adding this

[TG1999]

https://docs.google.com/document/d/1zKKVIV93OfrkOVU1lGj4X4oju1_8b45QeEgqRwOLTOc/edit?usp=drivesdk but in this doc, it was given already that we need to provide email to the admin @jaskirat2000 . Please resolve this query.

[jaskiratsingh2000]

Thanks for it, I think I also mentioned that this doc is just for idea, if things don't fit accurately we should not proceed, what do you say ?

…

On Fri, 12 Apr 2019, 8:34 pm Tushar Goel ***@***.*** wrote: https://docs.google.com/document/d/1zKKVIV93OfrkOVU1lGj4X4oju1_8b45QeEgqRwOLTOc/edit?usp=drivesdk but in this doc, it was given already that we need to provide email to the admin @jaskirat2000 <https://github.com/jaskirat2000> . Please resolve this query. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwTq0YGJuslltz-v_78exWqN7Ylm-qhks5vgKB7gaJpZM4csH99> .

[TG1999]

I think then how will this product help in sustenance if maintainers cannot ask contributors about their disappearance at least one mail should be sent so they can know is the contributor interested or not or he/she is busy with something else.

[TG1999]

Without this feature, it will be just a community tracker which is very common.

[jaskiratsingh2000]

I agree with that, but do you think really that once the maintainer or admin sends an email and if contributor is bot interested to contribute any more will reply ? We need to think this in both way

…

On Fri, 12 Apr 2019, 8:39 pm Tushar Goel ***@***.*** wrote: I think then how will this product help in sustenance if maintainers cannot ask contributors about their disappearance at least one mail should be sent so they can know is the contributor interested or not or he/she is busy with something else. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwTq9R20KqYZD8OEhxftJcUGjiLaykKks5vgKGqgaJpZM4csH99> .

[jaskiratsingh2000]

I want others to comment on this

…

On Fri, 12 Apr 2019, 8:42 pm Tushar Goel ***@***.*** wrote: Without this feature, it will be just a community tracker which is very common. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwTq8jB9ltkFxK-RnMhvgHP_AD8boyDks5vgKJLgaJpZM4csH99> .

[TG1999]

Fine @jaskirat2000 I am getting your point, let's see what other's has to say.

[sarthak77]

@sarthak77 I am not sure about 4th point that we should really go for it or not, because sending emails to contributor ( who maybe don't want to contribute any more) can be a spam, so it should be like notifying on the same admin dashboard about contributors added, disappeared. Maybe it can be like a survey analysis on the board it self.

And do you have any ideas that once I shared like adding integration, for instance adding user to some trello board , etc try adding this

Maybe if someone wanted to contribute and was busy at that time could use this mail and inform the mentors about his willingness to contribute

[sarthak77]

Without this feature, it will be just a community tracker which is very common.

Yes I also think that it would not be very useful if we are using it just to track contributors.
Like we'll use API's to get data from github and then track contributors and this feature is already in github

[Rupeshiya]

@TG1999 How about adding "issue status board" for the maintainer where maintainer can see the issue which needs to be implemented or which is in progress (if in progress then assigned to whom and ask about the status) or the issue which is pending?
Also, we can categorize the badge colour like dev/null, dev/1, dev/2, dev/3, dev/4, dev/5.
What do you think @TG1999 @jaskirat2000 @atharva3010?

[pragun22]

@TG1999 How about making special looking badges for most active users ( By special I mean, badges which distinctly looks better or one could easily tell that there is something special about that contributor on seeing the badge).Or We can have colours on the basis of the level of activeness, for example, suppose most active users are represented by a purple badge and moderately active by a blue badge.
So If a user is one of the most active users his badge will be of purple colour, but if for any reason he is not able to make much contribution, the colour will slowly fade to blue and then slowly to fading away completely.
Also how about adding tags to badges like a top contributor or discussion moderator.
Also, I agree with @Rupeshiya 's idea about adding "issue status board", that would certainly help maintainers organising their work.

[atharva3010]

@jaskirat2000 I agree with you. Sending notifications asking to contribute is pointless. It will be spamming and would ruin the spirit of open source. It has to come from within the contributor, the willingness to contribute.

@Rupeshiya nice idea but, I guess we are already doing something like that with task manager project. Also, GitHub already has the exact feature built in under the "Projects" tab. So, it won't be beneficial to implement.

I like your idea regarding badge colors. Keep brainstorming! If you are free, can you please try to make a scheme to implement the same?

@pragun22 Great idea! Can you also please make the exact scheme of how we will implement it? The logic behind it?

I will also try to come up with an algorithmic approach for the same.

[atharva3010]

I was thinking that we follow a point based score and relative ranking system.
Here is how it goes:

1. We will fetch the list of all the contributors and their contributions using the GitHub Statistics api.

2. A point is rewarded for each issue raised.

3. Two points for submitting a PR.

4. Four points for a merged PR (once the PR gets merged, PR and issue will get closed, thus deleting their respective points).

5. Sorting the contributors wrt to their total score.

6. Rewarding the top 10% contributors (if and only if they satisfy the threshold) a dark green color badge. That indicates that he is a top contributor. Then the ones who are below him will get green, light green, etc. The color scheme is inspired from GitHub's heatmap.

7. As he stops contributing, he will stop getting points. His rank will go down and thus he will slip into green, then light green, etc. category. Thus, the color of the badge fades.

8. The admin receives notification whenever this transition happens.

What does everyone think about this?

[TG1999]

@pragun22 thanks for the suggestion fading idea is already their in the doc please elaborate on its working .

[jaskiratsingh2000]

@atharva3010 Thanks these points look good and I think we should take this in into consideration.

[sarthak77]

Shouldn't the points be re adjusted as points for raising an issue and merging a PR are same

[atharva3010]

@sarthak77 No, it's mentioned that there is 1 point for raising an issue and 4 points for a merged PR.

[sarthak77]

Suppose the user raises an issue, submits a PR and then the PR gets merged
Total points = 1+2+4-3=4
Another user submits a PR and then the PR gets merged
Total points = 2+4-2=4
And 1 point deducted from the user who opened the issue so for him net points added = 0
So shouldn't we just add the points and not delete them as it doesn't give true picture?
@atharva3010

[atharva3010]

Yeah. Nice observation @sarthak77. We need to take this in consideration.

[sarthak77]

Thanks @atharva3010

[pragun22]

@TG1999 My approach was similar to what @atharva3010 mentioned in his comment, that-

1. we will first fetch the data we need using GitHub statistic API.
2. Each Project will have its own scoreboard and according to that Contributors will be assigned badges.
3. For scoring, I thought of maintaining separate data structures for issues raised and for submitting PR and Merged PR, because maintaining separate data structures for values will help us in assigning tags also, for example, using only the value of the number of issues raised We can identify which users are good at looking for issues and assign them a tag of something like ' Issue Finder' and whosoever has maximum issue raised he could be assigned a sub-tag 'pro' for tag 'issue Finder'.
4. The total score will be calculated using a formula like - 300*(no. of issues find) + 200*(no. of ongoing PR) + 500*(no. of merged PR). I have given low weights to no. of issues find and no. of ongoing PRs because I feel like solving should be given more weight rather than just raising an Issue or submitting a PR(which may be not even good).
5. Sorting will be done on the basis of Total score and we can even generalise badges as 'Solvers', 'Issue Raiser' in different columns. So I think maybe multiple scoreboards one on the basis of overall contribution and others on the basis of specific activity can be maintained and badges can be assigned for the respective scoreboard/field.
6. The colour of badges will be given on the basis of their relative score in the scoreboard. The top scorer will be suppose given a dark purple colour with some golden styling and then going the down the scoreboard the colour will be changing to blue ---> dark green ---> light green ---> completely fading away.
7. The relative order can be on the basis of either their rank or score. For example, if we are assigning badge on the relative basis of their rank then suppose the first rank is given colour purple and 10th rank is given colour blue, so in between colours will be calculated by interpolating these colours where the respective distance will be the difference in their rank i.e. rank3 is at a distance 3 from rank1 and at a distance 7 from rank 10 so colour will be Rank3(R, G, B) = (7Rank1(R, G, B) + 3Rank10(R, G, B) ) / 10. If we are assigning colour on the relative score then suppose top scorer is at a score 1000 and someone has a score of 400, so then colour of badge of that person will have 40% Component of top scorer and 60% component of the lower shade colour of top scorer ( if top scorer had purple then lower shade will be blue).
8. what I could not think of was how to avoid if someone is creating useless issues or making random PRs just to climb up the scoreboard, how will be able to judge the credibility of issue or PR. One thing I thought was that if PR is not accepted or it is been more than a week than reduce the points of PR that we were given earlier
9. Also, notification can be given about every update major update to the admin.

[atharva3010]

@pragun22 Nice approach. Coming to your 8th point, @sarthak77 please suggest what you think about this, we can always close senseless issues, automate the process. That's why I wanted to dissolve the points if an issue has been closed. Also, we should not deduct points if the PR is lying unmerged, because it's the maintainer's responsibility to either merge it or close it. People can be busy at times, so it's possible that a PR goes unnoticed. Here, the contributor is not at fault.

[sarthak77]

So major problem is with deleting the points as and when the issue gets closed or the PR gets merged which would not be giving true picture as discussed above. So what we can do is do away with deleting the points and side by side ensure that no user can climb the leader board by raising unnecessary points.

Issues
To give points only to sensible issues we can avoid unnecessary issues.
One way is to first discuss about the issues on the channel and if many are in it's support, only then it can be opened. At present also I think the same is going on that we first discuss the issues on channel and then open them.

PR's

• For PR's what can be done is that when we assign an issue to a particular person, we increment the points only once irrespective of number of PR's he makes. This would ensure that he doesn't climb the leader board by making unnecessary PR's on one issue.
• Incrementing points only once is also valid because it's only the final merged PR is what helps in taking the codebase forward. If his PR gets merged then he'll get points for merging the PR as well which would in a way mean more points for a good PR.
• Also if his PR doesn't get merged we will not be overlooking on the efforts a person is making in solving an issue as we would have given him points for that too.
• Also making multiple PR's and making a single PR when your final PR gets merged should be considered equal in terms of points and effort.
• Also making multiple PR's and making a single PR when your final PR doesn't get merged cannot be differentiated much.

All this would do away with the need of deducting or reducing points which was causing the initial trouble.

[jaskiratsingh2000]

I am afraid that we are not considering building badges somewhere and multi integration system like i mentioned previously, showing if something related to trello, etc

[sarthak77]

@jaskirat2000 we are considering that. Here we were just deciding on how the points would be awarded so that we can find the colour of badges accordingly since @atharva3010 proposed the way of doing that.
And yes this can also be discussed at later stages after basic implementation

[jaskiratsingh2000]

Okay, i agree. Looking forward to it

…

On Sun, 14 Apr 2019, 12:53 am sarthak ***@***.*** wrote: @jaskirat2000 <https://github.com/jaskirat2000> we are considering that. Here we were just deciding on how the points would be awarded so that we can find the colour of badges accordingly since @atharva3010 <https://github.com/atharva3010> proposed the way of doing that. And yes this can also be discussed at later stages after basic implementation — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwTqxujj0NJlJhwjg5JM6WZEKcEyO8Gks5vgi7DgaJpZM4csH99> .

[atharva3010]

@sarthak77 thanks for elaborating. Nice approach.

@jaskirat2000 I agree with you. Developing it as an integration is needed. For now, as @sarthak77 said, we are building a basic implementation, to show how it works.
Then, we'll go about developing it as an integration. Perhaps, we can also have it as a project for RGSoC. What do you think about this?