Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
Clone
HTTPS:
git clone https://vervis.peers.community/repos/yEzqv
SSH:
git clone USERNAME@vervis.peers.community:yEzqv
Branches
Tags
old-diary.mdwn
[[issues.dia]]
2014-03-04
The core of the ontology seems fine, but there are two things I’d like to talk about:
- Fully ordered categories
- Hot tasks
When I created the subclasses of Issue, I wanted to give them priorities. There were two options:
- Use a partial ordering relation to order them
- Assign numeric priorities
I went with the second option, because it’s much easier to work with when priorities make full ordering. This may be a mistake, because it’s possible a pair of priorities cannot be compared, but we’ll see later. Semantically it’s probably right to just express the relations between categories, and not meaningless numbers. But we’ll see.
The thing is, I began to have several of them and I decided it could be useful to have a full ordering class with a rating property, which would allow a general-purpose GUI widget or even a CLI tool to take a list of comparable items and sort them by the rating. Yeah, let’s try to add a TotallyOrdered class… TODO 1
As to hot tasks: A person may be assigned many tasks to handle, but it doesn’t mean she works on them all. It’s useful for her to see a list of hot topics being actively worked on, and for others to see her list and generate reports and statistics. How do I model this? TODO 2
Another thing, look at the Redmine docs: It allows to define a Workflow separately for each Tracker, i.e. each issue type. Check if it also means separate statuses, or just separate rules of status changes. Of course I also need to think about common statuses to put in the diagram, and consider modeling statuses by operations done and recorded, rather than as just states, e.g. automatically detect operations and change the issue state, e.g. git commit can auto-close an issue (supported by redmine iirc) and a feedback discussion marked as finished can make a transition from feedback state to something else… and so on. TODO 3
2014-03-05
I’ll update separately on the three issues, and another one I’m adding now: Attachment of diary entries / blog posts to tickets / aspects / other things.
- total order
I added classes and made the issues ontology support them. But then I realized, is there a reason for this to exist? Which information / meaning is documented through TotallyOrdered? It’s like using an abstract base class where templates can be used in C++. Why rely on a single central class? Next: Write some queries involving the total orders and see if TotallyOrdered is useful to them.
- hot tasks
I wrote about it on paper, need to add it to the diagram.
- redmine workflows
Not checked yet.
- diary
I added it to the diagram, but right now an entry can apply to an Aspect or to a Ticket. Next: Maybe unify Aspects and Tickets under a single baseclass? Or think, to which kinds of things a development-diary entry can apply? Are Aspects/Projects a good way to model continuous effort, as opposed to always-open toplevel tasks?
2014-03-06
I’m adding a new issue: Chain of task assignment.
- total order
(see last post on this issue)
- hot tasks
I updated the diagram according to the paper.
- redmine workflows
(see last post on this issue)
- diary
(see last post on this issue)
- chain of assignments
It’s possible that one person passes full responsibility of a task to another person. It’s also possible that a main developer passes (assigns) a task to a contributor, but remains responsible and manually reviews the patch and then applies it.
Q1: Is it possible to have a chain of assignments? Q2: Can any user be responsible and/or assign tasks to others?
First, the model: Each ticket has a chain of assignments. The initial responsible person either tool responsibility manually, or each new ticket is auto-assigned to a manager or some dummy user, e.g. “team”.
When a ticket is passed, the recipient is the new top-level responsible body for it, and the assignment tree of the original responsible person can either be copied, or be removed so the new responsible re-assigns it if/as she wishes. But of course someone assigned a ticket is not necessarily authorized to pass or assign it to someone else.
[[assignment-workflow.dia]]
Only some of the users are allowed to assign or take responsibility of or pass tickets. The permission ontology needs to be involved. The assigned attribute can be inferred, but storing it can make the access constant rather than linear. On the other hand, the assignment chain will usually be trivially short.
First, updating issues ontology… done. Now, what about the other thing, the permissions? Here are some ideas to consider:
- some users can assign tasks to others, and some can’t
- some users can make other users responsible for a task, and some can’t
- a user responsible for a task may have permission to pass responsibility to someone else
- a user may be able to take responsiblity over an unassigned task
- a user may be able to “steal” responsibility from another user
- a user may be able to assign to herself a task assigned to another user
- a user may be able to request to assign a task, and the target user needs to confirm
- a user may be able to request responsibility passing, and the target user needs to confirm
- a user may be able to request to be assigned a task, and the current assignee needs to confirm
- a user may be able to request to become responsible for a task, and the current responsible needs to confirm NOTE: Requests don’t have to be modeled: Free true warm human communication may be used for doing requests
Possible permission applications:
- specific task
- task and its direct dependencies
- task and its dependency tree
Okay, I looked at the permission diagram, and it seems generalized enough to enable these models of permission application. I’d like to talk about another issue, which I noticed while looking at the diagram.
When a rule is applied to a Target, it can be applied to the target itself (if it’s a Resource) or to its members (if it’s a ResourceGroup). The same concept works for User and Group in permissions, as well as for User and Team in issues. It begins to seem like a pattern: When applying a concept to an object, a machine should be able to determine the object is actually a group (i.e. a set defined by its members) and apply the concept directly (or recursively, depending on context) on the members. Here’s a model:
Currently, everything is an Entity and every Entity is either a Value or a Resource. Every Resource is either a Class or a Property or none of them.
In the new model, every Resource is either a Set or a Property or none of them. And every Set is either a Class or a Group, which have the following semantics:
- Class: A set representing some abstract concept, and each member of the class has the concept applies to it. Example: From a given statement “John is a member of the class Person” we can conclude that “John is a Person”, i.e. we have some meaningful information about John.
- Group: A set defined entirely and solely by its members, having no implied or built-in meaning of any kind applied to its members. For example, assume you want to document your friendship with people. The semantic way to do it is to have a symmetric property isFriendOf between two people, i.e. Person objects. But for now, assume you just want to start making some liat on your computer without telling it what it means. So you just create a new PersonGroup called “my friends” and make some people be members of it. A group has no meaning, it’s not standardized or used in generic queries or query templates. It’s just a way for users of the computer to say “these people together belong to this list” and be able to change the content of the list arbitrarily, even based on feeling or mood or personal preference, and not based on some trait of the person (which is how Classes work).
DECISION: Accepted.
TODO 1: Make a well-defined list of actions using the lists above TODO 2: Add the concept of Groups to the expression model and make Team, Group, TargetGroup etc. use it (it may be ok for now to add Group just in the ontologies, i.e. not necessary to add it to the expression model diagrams and documents… take a look at those materials, see how easy it is to make an update)
2014-03-08
total order
I thought about it and decided to keep TotallyOrdered. It allows you to list all the totally-ordered classes and use the total-order traits and rely on them when doing some operations. It is a general concept just like Class and Property are. Since the abstraction doesn’t do any harm and shouldn’t be hard to remove, I’m keeping it.
Example of usage: Convert all the integer total orders - or a specific subset of them - into equivalent floating-point values.
Issue closed for now.
hot tasks
When someone declares she works on a ticket:
- Does she have to be the assignee of the ticket?
- Does she have to be in the tree of assignment of the ticket?
- If a task is hot, does it relate to parent/child tasks being hot?
3: Only tasks worked on directly are marked “hot”. It is inferred that a parent task “proceeds” or “advances” if a subtask is being worked on, i.e. is hot. However it’s possible to mark a parent task as hot too, e.g. a manager doing arrangements to fulfill a large task on the high level, regardless of whether the workers are “hot” on its subtasks.
1: It sounds okay to have one/several users assigned to a ticket, as in “responsible to get it closed”, but for other users to help work on these tickets. Ex: a ticket that draws attention. A single user makes sure it gets closed, but other people help and make patches and so on. Another model is this: Before you work on something, you have to be assigned to it.
Q1: Which model is better/correct? Q2: Any chance both are good, and I can just let the user choose which one to use? For example, make work and assignment independent, but allow to define a property that is a subproperty of both, thus binding them together.
Hmmm… yeah, it can work. Another idea: Allow core developers to use a binding property which means they only work on what they’re assigned to, while other contributors can work on something without being assigned to it, so tasks are still watched and managed by the core team. Accepted.
2: In an hierarchical team, a person cannot work on something she’s not assigned. However, if a manager assigns a task to her worker, she can work on the worker’s task too. In other words, it can make sense that anyone in the assignment tree of the task can work on it.
Issue closed.
redmine workflows
(see last post on this issue)
diary
(see last post on this issue)
chain of assignments
(see last post on this issue)
2014-03-09
redmine workflows
(see last post on this issue)
diary
This is what happened last time:
“I added it to the diagram, but right now an entry can apply to an Aspect or to a Ticket. Next: Maybe unify Aspects and Tickets under a single baseclass? Or think, to which kinds of things a development-diary entry can apply? Are Aspects/Projects a good way to model continuous effort, as opposed to always-open toplevel tasks?”
Observation: Every diary entry can have a “topic” or “related concepts”, i.e. the things the text describes and what is written about. Therefore, in general a diary entry should be able to express the topic - just like any other document can - and this topic can be any concept, which means any Entity basically.
Then, you can have special diary entries which talk about some Aspects or specific Tickets, and they can have their subproperties with appropriate ranges.
Next: “Implement” this in the ontology diagrams.
chain of assignments
(see last post on this issue)