-
Notifications
You must be signed in to change notification settings - Fork 2
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
❓ Do we keep a column for completed issues? #13
Comments
Last DUNA meeting together, we briefly covered the ideas around when to and how to distribute governance tokens. I've been thinking about this for some time in the context of rewarding open-source work. This led to my implementation of a personal project tracker. In the context of keeping closed items un-archived, might I explain the logic behind some past choices? The largest principle behind all this is making sure we can properly attribute development efforts to the people originating them. I think the system we use for governance, capital distribution, and other working rights should depend on the work-product you achieve (what else is there to reward in an efficient society?) This is why my first thought about your issue was that there should be a column for each contributor, and the items they close out would move on a per-person basis to an archive. But upon writing this out, that could get pretty unmanageable over time. Notwithstanding, I also agree that just the sum total number of items will balloon no matter the column organization. This is a reality that differs from my implementation, where there are only so many things I can do in a given year, and I archive each task on an annual basis. But these are high-level asks, not individual actions like here. The main reason I keep the total archive is so that there can be a record for any interested parties to observe exactly what's happened to my work. But in the case of our items applying specifically to the WhyDRS org, there is a way someone can come in and see that you've helped (without manually examining a personal project board or such). Namely, we can use these contributions as inputs into the token distribution framework (whether automated or done by people like us). We talked about different frequencies for distributions, which is still up in the air. For conversational sake, let's say every month we go through everyone's contributions and vote on how much the aggregate assistance progressed the mission. After we somehow agree and distribute tokens to the person(s) who did the tasks, we can archive them from the project—sort of like a "stack" of pending reward completions, in computer science speak. This could also let us take into account the fact that some completed issues could represent months of work, whereas others could be a little simpler. A potential implementation of this could be a column for "Items completed in November - pending award" and so on, whereby the entry gets deleted after a quorum on token value of help and support. Then this gets into the voting design I'm working on, which needs to be balanced so that one actor doesn't compound all their work into controlling half the governance influence. Since the underlying items stay on GitHub, perhaps the distribution mechanism could reference the exact work items when available through explicit URL, so that the archive doesn't completely remove all future knowledge of how contributors got tokens. |
Thank you for the well thought out response, and I am 100% in agreement with the idea of having completed tasks sorted in a way that can accurately show contributions over a period of time. A separate column per month makes sense to me, and we can discuss how to potentially implement that history into the tokens themselves (in addition to the history of issues available on Github). To be prepared for scaling (and for an increase in the number of columns every month) I propose having a separate project set up just for completed issues. From there we can discuss pros/cons of having those columns labeled by month or by contributor and ultimately deciding on one. |
aloha, can I first shout out you guys are crushing it! I feel like watching house and miller making millions on their MSTR gamble and I missed the boat. ok, back to the topic. I think the completed issues should be completed and hidden or discarded. because there will be so many issues and having them visible could cause a newbie to crawl into a rabbit hole and not know these are done and pursue a lot of completed tasks. I used to work in a restaurant(this is where the owner gave me the nick name missing link)and one thing he said has stuck with me all these years. a good waiter is never seen and never needed. the people are there to entertain their friends and not chat with a waiter. I guess I see this completed issues as part of the wait staff. they 'were' issues, but have been fixed, and now people can enjoy the website, not even knowing you were here. Just my opinion though. 2 Cents. |
See image below. Should we keep a column of issues that are completed in the Organization Issues project? If so, do we add the issues that have already been completed and closed? I think it may end up filling up the column and get overwhelming, and could distract from issues that are either open or in progress. If this data is necessary to collect, I suggest a new project be created for completed issues.
The text was updated successfully, but these errors were encountered: