-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could we use project board method to separate list update PRs from administrata #1008
Comments
This seems like a lot of work for limited value. I’m concerned about the
amount of overhead being introduced, but I appreciate the continued
volunteering.
However, I’m not opposed, assuming it’s fine for us to continue to ignore
it. If this requires us to adapt new workflows, I don’t think it’s worth
the investment compared to the end goal: which is automating ourselves away.
|
I get that project and lanes might be a bit much. Just seeking a method to
do faster reviews without opening up stuff I didnt need to and pick up
where I left off or need to nudge folks on
I would like to set up either labels or use project to build some
stratification to pr and issues. Either one could work, but projects have
some automation steps that cut down on clicking
I tend to focus on the pr and issues related to entries in the list
There are pr and issues like this one we are updating which are meta or
documentation
There are many that are related to the testing/automation, documentation or
other stuff unrelated to the list entries which I dont have as much to
contribute on.
Selfishly, I see labels or projects as the path but I am one of many here
and dont want to proclaimeth anything
…On Wed, Apr 8, 2020, 7:57 PM sleevi ***@***.***> wrote:
This seems like a lot of work for limited value. I’m concerned about the
amount of overhead being introduced, but I appreciate the continued
volunteering.
However, I’m not opposed, assuming it’s fine for us to continue to ignore
it. If this requires us to adapt new workflows, I don’t think it’s worth
the investment compared to the end goal: which is automating ourselves
away.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#1008 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACQTJNL6WR2LZQUB4I2TKDRLU2THANCNFSM4L7NH3BQ>
.
|
This is kind of related to #967 - I work through the web interface and am looking to optimize the workflow on the requests that come through and getting them through the funnel efficiently. |
Here is a summary of the PR/Items as of this morning (I've closed a number of these, since but it shows the split): Within them, I'd like to be able to know where they are at in stages so that I can demonstrate a bias for G.S.D. (gettin' stuff done) without having to open each one, read it, and do stuff and repeat. I don't want to proclaim or define a process, but rather just leverage some of the benefits we have within GitHub's UI to help make the volunteer cycle more efficient. I have gathered the PRs and Issues together and split them into two buckets
My initial ask in #967 was to use labels to provide a visual indicator on the PR or Issue summary results page to at least flag ICANN or PRIVATE - which would infer "List Edit". It does not solve the 'what needs to happen next' part, which is where project board might be helpful. This is espcaially true in the Meta stuff, which has a much longer tail on it. This doesn't really track what stage they are at - and I think that will be helpful. I have had abundant cycles in the past two weeks, but will return to the time constraints of dayjob [hopefully] soon, which means dropping in with less frequency. We all get cycles to invest when we get them. Being able to see where to step in and quickly move some things forward where appropriate is something I think can be good for all of us. In the past, I've lost volunteer time to getting acclimated or figuring out what needs what.
|
Thanks! This is all super helpful.
Yeah, like I said, I'm not opposed, as long as it's not introducing or
adding steps to triage and label stuff. I'm bad enough with forgetting to
set r=sleevi vs indicating Approval on the merge request, and so just
trying to avoid having to do extra steps. Similarly, just trying to
understand the goal to make sure we're aligned, but strongly supportive of
whatever helps you personally achieve that if the goals are aligned :)
… |
@sleevi I have this set up - the project boards have actions that move the cards on the kanban columns. I have a q: how is r= intended to work as a label? |
OK so I have added two projects to publicsuffix organization:
The first, List Add/Mod/Del, is for the general PR/Issues submitted inside of publicsuffix/list They each have kanban type cards for each issue or pr, and columns for their stage of progress to quickly see visually where things are. There is automation within GitHub that will migrate the majority of what our activity is, with the exception "awaiting feedback" where we have a q or need feedback from each other or the submitting party.
I don't expect this to impact any of our process, other than to more quickly identify the items that are already being worked on to avoid losing time on those. |
I have been working through the backlog of PR/Issues, and it seems like there are some general buckets:
This is not exhaustive. Open to what these are called but would want it narrow.
It would greatly help organize stuff a bit to perhaps go through and assign issues and PR to projects.
No project assignment = needs a look
I am not proposing epochs, timelines, sprints, or milestones at this time.
@sleevi @weppos could this work, and also would it break or impact any automation
The text was updated successfully, but these errors were encountered: