This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U7213XMGS3H
Our org is considering adopting a kind of “Package level guide” that we can use to categorize packs and track our progress. I’m curious if anyone has tried something similar and has feelings about it. Is it awesome? Misguided? Any lessons we can learn from other companies would be fantastic
Message originally sent by slack user U71V6G2PDJS
I think I’ll have to borrow this 
Message originally sent by slack user U7213XMGS3H
I should credit Jeff Ammons (not in this slack) with the original idea! His version had 4 levels and split my level 3 basically down the middle. We’re trying to decide if we want 3 levels or 4. The jump from 2 to 3 feels big in this version, but with his 4 levels the difference between 3 and 4 felt arbitrary.
Message originally sent by slack user U717FXJ8HWK
We do something similar, not in form of a table, just a document describing what the packages should be, and in what order we should achieve those requirements (similarly to levels here).
I think this idea works. What is more, for some of the requirements it would be possible assign a rating/level to every package automatically.
Great idea!
Uuuuh… if you track these directly in the package.yml metadata, you get versioning and the chance to build tooling around it. 
Message originally sent by slack user U7213XMGS3H
@franzliedke I was thinking about something similar… putting level in the pack metadata and having conditional CI checks based on that
This is nice. Really nice. But I need some clarification: Are you stating that every pack should aim to get to level 3 in that chart? I don’t think that’s be desirable. But this looks like that would be the goal.
IMHO some of the rows in here can be totally optional, but only the last one says “if necessary”.
Message originally sent by slack user U7213XMGS3H
That’s a good question. We think most feature packs should get to level 3. We have a big, old codebase, and I know that not every pack will, and I even think it’s likely that some shouldn’t but the ones that shouldn’t are sort of the long tail. But, we’re embarking on this modularization journey for the first time, and this is exactly the type of question I want feedback on
Yeah well… we’re also very early in our modularization journey on a project which is over a decade old (although kept up to date and constantly evolving) and ~ 85KLOC. And we decided our first goal is between your Level 1 and level 2. A row you don’t have that, I think, should go right bellow “Files exist in a pack”: Reduce to the minimum (hopefully zero) “architecture” violations/todos.
So we’re focusing on that even before trying to resolve “dependency” or “privacy” issues. "architecture is a better first target, we think.
Message originally sent by slack user U7213XMGS3H
Tell me more about “architecture” violations
and focusing on that will also resolve a bunch of “dependency” issues too, even if that’s not THE first goal.
Message originally sent by slack user U7213XMGS3H
ah yes, i’ve seen this. we’re not using it yet, but maybe we should be
I’ve been sending many PRs to https://github.com/rubyatscale/visualize_packs and a couple to https://github.com/rubyatscale/packs to make those tools more compatible with “architecture” violations/todos.
@stephan has been kind merging most of that.
I do think it’s great that Packwerk emphasizes bringing value even at the low levels already. It’s good to embrace that.
Message originally sent by slack user U7213XMGS3H
yeah we wanted to emphasize that level 1 is very attainable and gives some value up front
I think defining a set of 3-6 architectural layers, assigning packs to each layer, then focusing on those architectural violations… is a fantastic 2nd step (after moving most or all your main app’s files into packs)
Message originally sent by slack user U7213XMGS3H
What are your layers?