as an admin, i want users who 'start work' to start a PR within 24 hours, so i can be sure they're serious

[owocki]

User Story

as an admin, i want users who 'start work' to start a PR within 24 hours, so i can be sure they're serious

Why Is this Needed?

Summary:

because too many people wait too long and sit on tickets without working on them

Description

Type: feature

Current Behavior

users have several days to comment after they start work

Expected Behavior

users will have 24 hours to submit a WIP PR

Solution

Summary:

• make the user agree to start within 24 hours on the 'start work' modal
• kick user off the ticket if they don't oblige

[SaptakS]

@owocki I feel this might always not work since the user might actually start working but haven't done anything significant to create a WIP. I mean we should give a warning (or maybe allow to extend) rather than kick off so as to allow for flexibility a little bit. Maybe something like, give a warning, and if he/she doesn't comment with something reasonable within 4-5 hours kick the user off, or if their reason isn't good enough (for the admin) then the admin can themselves kick the user off.

[dolebas]

One way of following up on the progress maybe could be to encourage a discussion in the Gitcoin Slack?

After posting my first bounty on Gitcoin I referred to my Gitcoin Slack user and encourage a pm, which was a great way to start a healthy dialog.

In retrospect I think creating a dedicated slack channel for the bounty would have been even better as the discussions became quite fruitful with regard to shedding light on the particular issue.

If anyone comes in later it would be great to have a link from the Gitcoin bounty (open or closed) to the dedicated Slack channel for reviewing a more informal discussion regarding the issue.

What do you think?

[mkosowsk]

Like this concept! Good to have tight feedback loops 👍🏻

I've thought previously about requiring contributors to submit a Plan of Attack or Action Plan within 24 hours after starting work, basically how they will go about about tackling the issue. This seems to be going pretty well with @KamesCG and some uPort bounties.

I'm unsure if it's best to have a WIP PR, an Action Plan, or both but anything that requires the Contributor to put some thought into how they want to get the damn thing done is a good thing :)

[dolebas]

👍🏻 Detailing a draft plan would probably help the developer into a constructive work flow as well

[mkosowsk]

@dolebas I agree! 👍🏻

Here's an example on the uPort side of things where the Contributor started off with a draft plan that I think really focused the efforts: https://github.com/uport-project/buidlbox/issues/2

[SaptakS]

@mkosowsk Yes. I think the contributor can comment the draft plan as well in the github issue and we can consider that to be one of the criteria to check whether they have been active within the first 24 hours. That might actually work better than getting a WIP within 24 hours and will also promote discussion.

[thelostone-mc]

+1 for action plan by the hunter as against a WIP PR
This would make sense even for design issues where a PR need to be submitted

[dolebas]

Thinking out loud now but if a PR with an action plan would be submitted even before work is started, it could enable several candidates to compete and create an incentive for drafting a good action plan?

If the repo contains a template for an issue resolution action plan, it could simply be forked, edited and submitted by each candidate. Comments relating to each plan would be structured under each PR and the bounty funder could compare and review submissions before work is continued.

Focusing workflow to Github as a canonical source could possibly also introduce some interesting ways of leveraging Slack/Discord bot integration?

[SaptakS]

Thinking out loud now but if a PR with an action plan would be submitted even before work is started, it could enable several candidates to compete and create an incentive for drafting a good action plan?

Sorry if I am taking this in a wrong way, but I think most open source organizations promote working on several different tasks instead of competing on the same task. If someone fails to deliver or the work is unsatisfying, surely we can consider someone else's solution. But in open source, I feel it is more about making both the developer and maintainer reaching a mutual understanding through which both get to learn something. That is how I feel personally. If we make it in the form of competition, we would be discouraging new comers, who with proper guidance can actually serve good. Sorry if I said something wrong or rebelious. My personal opinion completely. Also, correct me if I am wrong, I feel that the current workflow of gitcoin anyways allows only one user to be working on one issue at a time and multiple contributors can't start work, until re-opened.

Focusing workflow to Github as a canonical source could possibly also introduce some interesting ways of leveraging Slack/Discord bot integration?

I completely agree with this point. There can be huge feature integrations here to not just consider github issue comments or PR as work but also slack involvement and discussion.

[thelostone-mc]

@SaptakS we do allow multiple users to startwork at this point (I'm hoping cause they are collaborating on it although we still don't have the ability to split the bounty during collaboration )

Example: https://gitcoin.co/issue/MARKETProtocol/website/24/337

[dolebas]

Thanks for sharing your thoughts @SaptakS and I do agree with your view on the many benefits of the open source culture. Keeping focus on collaboration rather than competition is probably a good thing.

Maybe the action plan/PR template model could work in this context as well tho?

[owocki]

cc @vs77bb on this

[owocki]

re multiple ppl starting work on the same issue => https://github.com/gitcoinco/web/issues/973

[vs77bb]

I like the Action Plan and/or WIP PR. I wonder if we ought to make this required before clicking 'Start Work'... i.e. when you click 'Start Work', you are prompted for an Action Plan (which is a required field). I know this is in @PixelantDesign's updated 'Start Work' flow but I can't find the ticket and don't know whether it's required

The even more heavy-handed approach is similar to Upwork, where you click 'Start Work', submit a required 'Action Plan', and are not automatically accepted for the role. The Funder then chooses amongst those who submit action plans and one of them 'Start Work'.

This could be incorporated in #973 when a funder wants to review multiple candidates for a potential high-touch bounty bounty.

[dolebas]

What if the 'Start Work' button would automatically connect to GitHub > fork > open PR referencing the issue > provide template for the action plan in the comment? All within the Gitcoin ui.

[mbeacom]

@dolebas That would require additional GH permission scope that we're trying to avoid at the moment. Also, I'm not sure requiring a PR before starting work is the right direction. I think submitting an action plan on Start Work makes sense, though.

[dolebas]

Ok. Sorry for being stubborn... GH permission scope can't be isolated to the fresh fork? Was thinking something like Netlify does with their button. If a symbolic fork is required early in the process, collaboration would have a natural place to start at and following up on the process would be easy?

[kuhnchris]

@owocki can you follow up on this?