🦾 Organization issue project workflows

[JFWooten4]

It looks like the projects tab only allows for the basic template actions. Unfortunately, I cannot duplicate the DB add or include more repositories therein by my understanding. It seems like migrating into a new workflow ought best help bring everything into one place (with categories?).

cc requester @JamesAlfonse

[JamesAlfonse]

Setting up a workflow using GraphQL, Personal Access Tokens and Workflows would probably be the easiest way to do it. A Github app could also be made, but that would require setting up a server. I think this may take a good amount of time, and it may just be easier to add issues manually to the project for now. I continued the conversation you started below, let me know what your thoughts are.

https://chatgpt.com/share/671dc643-e8fc-800c-9786-d3a9585ea26a

[JFWooten4]

@JamesAlfonse I love the idea of using Personal Access Tokens for accountability (GPT gave me a similar response, and your chat flow looks quite logical). It's certainly a new thing for me, and perhaps something to take a step back from to ask how we are using the projects board. I've been setting them up for much of my own work recently.

The more I think about it, the more it sounds like we're (possibly) giving people a list of things and being like "this is what needs to happen, go do it." Maybe you see it as something more organizational, and by all means let me know your thoughts on the potential here. But what I'm trying to say is that I think it's best when people like you and I decide independently what to work on, where to assign things in our own versions of projects, and so forth.

That train of logic is why many of my own projects are specifically written for my own understanding alone, using convenient shorthand that still keeps everything organized around outstanding GitHub Issues/PRs (generally that I've created or am collaborating on with someone else). But when we delegate those choices to a "robot overlord" (as dramatic as I'm making the automation bot sound lol), I just think it removes a lot of the fun that comes with discovering a unique challenge I'd personally like to solve—and then my own journey to go and fix it.

[JamesAlfonse]

@JamesAlfonse I love the idea of using Personal Access Tokens for accountability (GPT gave me a similar response, and your chat flow looks quite logical). It's certainly a new thing for me, and perhaps something to take a step back from to ask how we are using the projects board. I've been setting them up for much of my own work recently.

The more I think about it, the more it sounds like we're (possibly) giving people a list of things and being like "this is what needs to happen, go do it." Maybe you see it as something more organizational, and by all means let me know your thoughts on the potential here. But what I'm trying to say is that I think it's best when people like you and I decide independently what to work on, where to assign things in our own versions of projects, and so forth.

That train of logic is why many of my own projects are specifically written for my own understanding alone, using convenient shorthand that still keeps everything organized around outstanding GitHub Issues/PRs (generally that I've created or am collaborating on with someone else). But when we delegate those choices to a "robot overlord" (as dramatic as I'm making the automation bot sound lol), I just think it removes a lot of the fun that comes with discovering a unique challenge I'd personally like to solve—and then my own journey to go and fix it.

I totally get where you're coming from. It's challenging to motivate people to take on tasks that best match their skills, especially when automation is involved with those tasks. My vision for the projects board, like you mentioned, is more for organizational purposes. I want to make it easier for new participants to have a single page where they can see where they can contribute.

I still believe in the potential of this approach, but maybe we can tweak the system after we centralize the issues. Instead of automatically assigning categories, how about we structure the columns based on each repository? Since repositories are inherently organized, the automation could assign issues accordingly. Plus, we could organize these columns in a way that minimizes bias, such as sorting them alphabetically or by repository creation date, rather than manually assigning the positions, which could unintentionally highlight certain issues.

I really appreciate your insights and your willingness to think outside the box about potential challenges. I'm also open to other ideas for organizing issues or even shifting our focus elsewhere for now and revisiting this strategy later.

[JFWooten4]

I still believe in the potential of this approach, but maybe we can tweak the system after we centralize the issues. Instead of automatically assigning categories, how about we structure the columns based on each repository? Since repositories are inherently organized, the automation could assign issues accordingly.

Sounds like a smart plan to me! 🧠 I'm happy to configure you as an org Admin to handle these configuration logistics.[^tm] That sound acceptable to other admin @tehchives or at all helpful/desired, James?

[^tm]: Temporarily, at least. I know we're in the process of detailing the roles and custody things in the new DAO docs.

[tehchives]

Absolutely, it'd be very welcome. If James is agreeable.

I like the vision to have the tasks be organized by something empirical and separate from individual priority or bias.

It really is tough to get people to engage, and I think part of that is phrasing. When operating as a volunteer collective and developing this open source project from the ground up we've needed to wait for people to have the time and interest to contribute on their own, in the way they choose, aligned with their values and desires for the future.

Maybe as we grow and once we have operating funds we can organize some tasks (or nominate them) for users whose efforts are more specifically sanctioned and supported by those funds, but I think that's something for much later.

Another thought, perhaps we could set up a viewing area for tasks in the vein of John's dao.whydrs.org and call it something like tasks.whydrs or contribute.whydrs or volunteer.whydrs, etc etc, and maintain representation of issues in progress there. This might break down the barriers for contribution even further. I am not sure if that conflicts with the per-repo issue organization though.

[JFWooten4]

Great idea at the end. Off the cuff, I think it compliments the per-repo organization because now it's another parameter you can filter for if you have an idea on the topic you want to work on generally. E.g., a writer (traditionally) could stick with Comments, Petitions, or Docs; whereas a seasoned dev might immediately hover towards the Database, Historic LLM, or a flashy homepage.

I think it's about making things easier to understand. Accessibility drastically lowers how long it takes someone to understand what an impact they might create. E.g. there were a ton of local things on the ballot this election that I had no clue about, and even just a simple UI info 2-sentence explainer in plain English would've materially helped my decision-making.

[JamesAlfonse]

@JFWooten4 @tehchives Yes, that works for me. Also loving the idea of having a subdomain(s) set up for this! Would love to see how that could be fleshed out. Are you envisioning something more than just a redirect to the projects page on Github?

[tehchives]

Yes, at least in UI. I think (and forgive me for this) but the github UI is still limiting, despite how intuitive it can seem. A frontend page with a simple domain describing what we're looking for might incite more contribution! I am hopeful and optimistic this is the case.

This probably medium term wraps into the 'apes guide to github' idea.

[JFWooten4]

I second Chives' semantics and added James as discussed.[^2fa]

[^2fa]: Due also to establishment of 2FA.