Web: As a Funder, I'd like to see the latest information on who has submitted or applied to work on my bounty.

Created on 19 Aug 2019  路  14Comments  路  Source: gitcoinco/web

User Story

As a Funder, I'd like Gitcoin to clearly surface information I need to decide who I should choose for my bounty.

As a Funder, I'd like to see the latest information on who has submitted work on my bounty.

Why

It鈥檚 too hard for funder to vet quality applicants because I don鈥檛 know who are good people to work on my bounties.

Assumptions

  1. We are assuming that funders want to look for and select their contributors.

  2. We are assuming that having the appropriate information to select contributors will keep our funders satisfied and therefore, positively affect retention through an enhanced user experience.

  3. Tech - use same logic that exists today

Definition of Done

  • [ ] Move Accept and Submit sections to the top of the issue details - only Funders and people in their org would see this on the issue details (it can still display publicly on github).
  • [ ] Build in a success rate (number of bounties started / bounties completed)
  • [ ] Display flyout with additional information - for performance.
  • [ ] Review with squad

Data

  • ideally the data tracked should be which contributors were surfaced
  • which contributors they selected to approve/accepted submission

Additional Notes

Gitcoin Match will not be working until keywords and matching are fixed.
Related https://github.com/gitcoinco/web/issues/4888

discoverability (1)

sprint 18

Most helpful comment

I think what we'll have to do is to go through each Profile's bounties they've interacted with, and check for different types of activity in priority order, then go to the next bounty once the highest priority activity for each bounty has been found. Example:

activities = Activity.objects.filter(profile=profile)
bounties = [a.bounty for a in activities]
count_work_completed, count_work_in_progress... etc = 0
for bounty in bounties:
  if Activity.objects.filter(profile=profile, bounty=bounty, activity_type='work_done'):
    count_work_completed++
  elif Activity.objects.filter(profile=profile, bounty=bounty, activity_type='stop_work'):
    count_work_abandoned++
  elif bounty_removed_by_funder: etc...

Performance will probably suck but it might be the best we can do because of the logic behind activities being a series of actions that take place over time, and us not having any logic in the backend codebase that orders them properly. We have to do the ordering here by checking for the latest possible activities first and assigning the count for that bounty, then going to the next bounty...

All 14 comments

Looks good - note that the "people in their org" mention of the first item in the Definition of Done will change based on Andrew's work with syncing the Github permissions for shared management

Sounds good. Just to confirm - backend work will change in a future sprint once Andrews part is complete, correct?

If we're displaying the same buttons for other org team members, not much else will change on this screen. Aside from, a contributor could click on an org logo to see who else is in that org - in the future.

While debugging the addition of Organizations #4969, I noticed that there is a mention to the profile.organizations object, originally indicating it was apart of the profile table, it seems to be that the organizations object it references in user_popover.js is an array of interactions on the site, bounties, etc, and the concept is to showcase the logos(i think) of each org that they have worked with.

A note while going through this is that the hover card currently appears to sync the profile of the user it hovers, hitting github + the db for each hover. suggest a caching strategy and defer to syncing underlying data via a cron job.

"Move Accept and Submit sections to the top of the issue details - only Funders and people in their org would see this."
For this we will need to change all the logic of that page, as discussed on the meeting.
Anyway I have a question, Why other people can't see if someone was accepted? Or submitted work, Is exposed in Github issue comments and also an important factor to understand if someone is working or not on a bounty.

The original thinking was that contributors might like their ideas to somewhat be a secret so that other hackathon participants didn't see this.

The hackathon funder IS interested in seeing a thorough and thoughtful idea of what the contributor would be building, based on the feedback we've received.

We chatted with @alexvotofuture last week and came to the conclusion that it would be easier to display everything publicly for now on github, so we could go that route. I'll update the ticket.

cc @frankchen07 @vs77bb

I think for the popovers is like 5 points, since there are some complex queries we need to do to fetch ratings and last works and also fix the data.

Is that 5 points in addition to the 13 points scoped to update the sections on this page @octavioamu ?

@danlipert @thelostone-mc I have some technical questions about the data on that popover. Right now the data is not right because is using activity data:

image

So the problem with activity data is that data is not at state of an application, if you apply to work, stop to work, submit work in the same bounty that actually will be 3 entries in the activity when we actually want the state of the application "work submitted"

So I believe we can solve this in many ways but I want to discuss since the correct data could be from bounties, but also a lot of queries (?)

Or maybe we can use the activity but checking the last activity related to a bounty instead of counting all activities in that bounty?

Then also we have the other bounties a user made and contain the same keywords and the ratings (if exist) related to that bounty.

Not sure what will be better

@willsputra There is a "view more..." at the bottom where that goes?

I think what we'll have to do is to go through each Profile's bounties they've interacted with, and check for different types of activity in priority order, then go to the next bounty once the highest priority activity for each bounty has been found. Example:

activities = Activity.objects.filter(profile=profile)
bounties = [a.bounty for a in activities]
count_work_completed, count_work_in_progress... etc = 0
for bounty in bounties:
  if Activity.objects.filter(profile=profile, bounty=bounty, activity_type='work_done'):
    count_work_completed++
  elif Activity.objects.filter(profile=profile, bounty=bounty, activity_type='stop_work'):
    count_work_abandoned++
  elif bounty_removed_by_funder: etc...

Performance will probably suck but it might be the best we can do because of the logic behind activities being a series of actions that take place over time, and us not having any logic in the backend codebase that orders them properly. We have to do the ordering here by checking for the latest possible activities first and assigning the count for that bounty, then going to the next bounty...

in that case is not better to just fetch bounties + interest? instead of activity? since also we need to filter the ones related to skills of the current bounty.
something like Bounty.objects.filter(profile=profile)

From our engineering chat:
Dan will add a cronjob to calculate success rate and store in user profile daily
Other data will be loaded directly on mouseover

@octavioamu @thelostone-mc So I ended up with something similar and quick to calculate in #5104 - Its the same calculation that we show in the quarterly stats so I figure we can start there and adjust with a more sophisticated algorithm that we can cache if we need to in the future

@octavioamu @thelostone-mc Note that Vivek reported that there are some issues with the mouseover logic resulting in the popover getting stuck
image (2)

  • lets make sure that gets fixed with this issue.
Was this page helpful?
0 / 5 - 0 ratings