Monocle workspace for Haskell projects

Show and Tell
#1

Hello folks,

We are pleased to announce a new workspace created on Monocle’s public demo node:

Monocle is a free software (GPL) written in Haskell, it helps teams and individuals efficiently organize daily duties.

You can find the configuration here: demo-node-config. Feel free to propose changes to the project list. We would be happy to include the changes from gitlab.haskell.org.

Please let us know if you encounter any issues or if you would like to contribute to the project!

Bests,
-Tristan

9 Likes
#2

I’m a bit too tired to interpret Dhall code in my head; what is this for/about?

#3

The Dhall code defines the workspace. It contains the list of repositories to index and some settings such as project/user groups or search aliases that can be used to customize the views.

For example, we configured a core-libraries project group so that you can see the list of open changes on any core libraries through: https://demo.changemetrics.io/haskell/board?q=project:core-libraries (you can add and (not repo:haskell/cabal) in the search bar to hide cabal)

We could also define a bots group to remove them from the metrics using the not bots search filter.

2 Likes
#4

I think it’s a richer version of Github’s repo Insights tab, with support for several of the major public code hubs.

1 Like
#5

Thanks to @chreekat the workspace now contains GHC. As @simonmic mentioned, Monocle’s strength is to aggregate item from different sources into a single view, so that for example, an Haskell developer can check the board to see what’s happening on the compiler hosted on gitlab as well as the libraries hosted on github.

Though the initial use-case was for Gerrit, and the GitLab changes draft/approvals criteria are not (yet) correctly filtered on the default review board page.

2 Likes
#6

Very interesting. :slight_smile: Note that unfortunately GHC’s metrics will look pretty wonky regarding “changes abandoned” because the GHC workflow relies on marge-bot, which has an ugly tendency to close MRs as “not merged” due to automatic rebasing that GitLab can’t follow. That is, the changes do get merged, but the GitLab interface says otherwise. I personally think this is actually bad (these metrics matter for encouraging contributors!), but nobody currently has time or the will to fix it. To anyone reading this: talk to me if you’re interested…

1 Like