Would this not imply central control? I would imagine locking a conversation from someone (or everyone) by un-tracking that user and not fetching their updates.
This came up in our jam session, I believe. We were thinking about the semantics of what would happen, i.e. would it be merged into some branch representing the closed issue. For the data definition I believe it would represent a āCloseā op.
In general, for the first draft Iād like to assume:
a) Authors can take any actions.
b) Authors can only do editing actions on items that they create.
So this would mean that the author of the issue would close the issue. In the second phase of this feature it would make sense to think about who can do what with some sort of permission system
@xla Closing and ACLs are two very distinct operations semantically, and Iām asking to flesh this out in more depth.
In particular:
What does it exactly mean to close an issue? Should it be preserved as part of the project somehow? Should it be possible to simply trash issues? For past issues, what kinds of queries should be possible against this corpus?
It is conceivable that, in a non-adversarial setting, ACLs published by (somehow) privileged participants would be followed by others. How exactly, however? What is the point in time the ACL comes into effect? What happens around this point in time (remember the replication model is eventually consistent)? What are the semantics when someone doesnāt follow the rules, and references objects which do fall under the ACL?
Itās exactly a rose tree I found a Rust implementation, but need to explore how useful this is for us. Also the list has other semantics, it should be ordered and unique. So a Set might make more sense instead
Didnāt think about uniqueness actually. Hmm. Also I guess it would have to be a BTreeSet if you want ordering. It seems weird, but I guess itās possible for elements to be added in a random order?
Thinking about it again, maybe the point is that we donāt embed the semantics of ordering in the denotations. These things can be isomorphic to each other.
But Iām not quite sure about this nuance. Iāll have to pick Sandyās brain about this tomorrow
As an ex QA manager I would advise not focusing too strongly on what the github issue tracker does. The github issue tracker is simply not that good. A lot of people use it because it is integrated with github and means they donāt have to host a proper tracker themselves. It is highly likely that radicle users will end up using whatever is implemented here for the same reason.
The good trackers to copy are Redmine, Bugzilla and for certain features Jira (I am not a fan but it is popular). There may be new ones I am not aware of as I have been out of QA a couple of years.
Some of these might not be feasible initially, or perhaps ever in some cases, but its good to have suggestions.
Key concepts that would be nice:
Fields should not be static, but rather maintainer configurable. A lot of bugs are useless without a specific piece of information but this could be anything depending on the project. Being able to set a mandatory field like āComponentID:intā can be very important. But you donāt want massive amounts of fields cluttering things for those that donāt need them. There are already a lot of suggestions for additional fields above, implementing all of them would be a mess for small teams. Implementing none of them would be a mess for big teams.
Automation should be facilitated as much as possible. This can save a lot of time on large complex projects. Given the architecture of this project there should be a lot of opportunities for the usual features such as automatically linking commits to issues mentioned in their commit message. Redmine has a custom workflows plugin https://www.redmine.org/plugins/custom-workflows-plug-in which is just amazing for a dedicated QA team, saving massive amounts of time on large projects. Something like this might be a bit much to ask for here. The basic gist is that newly reported/closed/modified issues are passed to a customisable script that can check, validate and modify, and also return the form to the user with an error message.
Issue status - the fact that github only has two is probably a design decision to keep things simple, but it prevents the tracker being viable for serious QA teams. Each project needs different statuses based on the structure of the organization and these should be customisable.
Workflows - github has no proper bug workflows. A tracker workflow is a set of rules that define for example under what circumstances a bug can change status. For example it might prevent an issue from being closed until it has been verified by QA, or it might prevent a critical feature being closed by someone who is not a maintainer. These should be configurable based on the needs of the project. Some small workflow rules have been suggested already in this thread (e.g. only author or maintainer can close). No one size fits all though unfortunately.
Link types - not critical, but nice to have. e.g. duplicate, parent/child, related
Proper searching and filtering- self explanatory, mostly a weakness in github because of the lack of fields and statuses
Migration - it should be possible to export all issues in complete detail in a machine readable format. See below.
A system like radicle or github may not need any of this. The majority of users are collaborating on small projects with just a few contributors, and a simple, low feature tracker is desirable. What this means however is that when a project becomes really large and complex, and the number of contributors becomes larger, the group is forced to either settle for wasting a lot of time and effort managing issues in a sub-optimal way, or migrate the issue tracking to another framework which can be a major undertaking and results in the development no longer being localised in one system, which seems to be a major goal here.
Sorry for the wall of text but I feel like issue trackers are of critical importance to good software development, and also that they are often neglected and have not been kept up to date with modern development tools.
This is awesome @Duncan! You have some really nice points and I definitely appreciate the links
At the moment, our focus is to get the simplest version up and running. This way we can spotlight any of the engineering concerns early. But, as that matures Iāll definitely be revisiting your input here and possibly pick your brain about some of the points
The good thing is that issues and other collaboration features arenāt necessarily tied to the protocol. That means we can test out different forms of data, as long as we can store it in our backing VCS (in one form or another).
Thanks for the feedback @Duncan. Really great to get some perspective from the QA side of things.
Yeah, this is really intriguing to me from the Radicle perspective imo. Since Radicle has peer identities baked in, thereās much more room to explore configurable rulesets / fields paired with user types (i.e. maintainers, authors). Iād love to strike the balance between delivering the simplest experience with just the right amount of customization & tooling that gives teams the ability to mold the experience to support their workflows. Makes the experience more intriguing & exciting, when you can mess around with it.
@brandonhaslegs and I run user research sessions to talk about exactly these concepts. Would love to include you in one sometime over the coming months if youāre interested
Yeah I was not expecting a fully fledged bugtracker any time soon, its not a crucial part of the core functionality. I just wanted to make sure these sorts of considerations arenāt ruled out by early decisions.
Contact me any time if you need further input.
I found a 
