# Productivity aid

**URL:** <https://discourse.pijul.org/t/productivity-aid/1003>\
**Category:** Development\
**Created:** [November 5, 2022, 9:43pm UTC](https://discourse.pijul.org/t/productivity-aid/1003 "2022-11-05T21:43:36Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![taqtiqa-mark](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/taqtiqa-mark/32/497_2.png) [@taqtiqa-mark](https://discourse.pijul.org/u/taqtiqa-mark)\
**Post date:** [November 5, 2022, 9:43pm UTC](https://discourse.pijul.org/t/productivity-aid/1003/1 "2022-11-05T21:43:36Z")

</div>

In a git, etc. all ‘patches’/commits are ranked equally - anyone merging a emailed patch or a pull-request has no initial/first-approximation guidance on how much time/effort might be required to approve a merge.

These tools offer no assistance in a first-approximation prioritization of simple vs. more complex changes.

With it’s more formal graph-theoretic background perhaps Pijul could provide encode/decode complexity metrics?

Several are likely possible, so a repository creator could nominate one when the repository is created?

However, for an initial release, perhaps the `p*c*log(h)` metric for both is sufficient improvement?

Nonetheless, the following would be added to a change:

```auto
Complexity-Metric: ....
Complexity-Decode: ...
Complexity-Encode: ...

```

So for a first release:

```auto
Complexity-Metric: Big-Oh
Complexity-Decode: 123.456
Complexity-Encode: 123.456

```

Or some such.

Thoughts?

---

<div class="post-metadata">

**Author:** ![taqtiqa-mark](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/taqtiqa-mark/32/497_2.png) [@taqtiqa-mark](https://discourse.pijul.org/u/taqtiqa-mark)\
**Post date:** [November 5, 2022, 10:52pm UTC](https://discourse.pijul.org/t/productivity-aid/1003/2 "2022-11-05T22:52:54Z")

</div>

Actually, maybe for a first release, `h` could be more usefully be replaced by the number of dependencies the change has? In this case the change approximates a repository. Anyway, you get the idea.

---

<div class="post-metadata">

**Author:** ![joyously](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/joyously/32/266_2.png) [@joyously](https://discourse.pijul.org/u/joyously)\
**Post date:** [November 6, 2022, 4:04pm UTC](https://discourse.pijul.org/t/productivity-aid/1003/3 "2022-11-06T16:04:02Z")

</div>

Having the number of dependencies wouldn’t help much. There needs to be more help in managing the dependencies, and it’s not just about applying changes. Unrecording a change is quite cumbersome when other changes depend on it.  
I wrote a [script](https://discourse.pijul.org/t/dependency-graph/933) to visualize the dependencies, but it would be better is pijul would prompt for how to handle these or at the very least list them.

Maybe a way to list the number of lines affected, number of files affected, and/or dependencies would give an idea of the complexity of a change. (But line oriented numbers are for text files…)

---

<div class="post-metadata">

**Author:** ![taqtiqa-mark](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/taqtiqa-mark/32/497_2.png) [@taqtiqa-mark](https://discourse.pijul.org/u/taqtiqa-mark)\
**Post date:** [November 7, 2022, 6:16am UTC](https://discourse.pijul.org/t/productivity-aid/1003/4 "2022-11-07T06:16:47Z")

</div>

All good points.

> [@joyously](#):
>
> Maybe a way to list the number of lines affected, number of files affected, and/or dependencies would give an idea of the complexity of a change.

I was trying to avoid such arbitrary/random metrics - for no better reason than personal preference. While `p*c*log(h)` has some theoretical basis, there are likely other metrics - so I suppose we are actually back to making arbitrary choices 🙂