Hi Paul, I love that you're going into the nitty gritty details of the constitution
Here is my take:
1) Is it possible to strike something from Governance if it is discovered after the fact it is NVGI (they do not have a valid tension, so should not have proposed it in Governance in the first place [3.2.2 of version 4.1])? I know normally NVGI is only within the meeting, but say there was a situation where I facilitated a meeting, and after the meeting, I discovered (through remembering conversation in the meeting, asking the Proposer afterwards, etc.) that they didn’t actually have a valid tension. Since a valid tension is a requirement to propose something in the first place, would that potentially count as NVGO, meaning it could be struck?
My interpretation of article 3.4.4 is that a Secretary can only strike governance based on the merits of the governance record itself, not on the tension that led to it being proposed. However it was processed and tested during the governance meeting carries the full authority of the governance process, and you would need another governance proposal to change it.
The Secretary doesn't have the authority to test proposals outside of the governance meeting. Make a parallel with testing objections: if an objection was integrated into a proposal, and the Secretary later interprets that this objection was not valid, they still don't have the authority to change the governance accordingly. The testing only happens during the governance meeting, unless it's purely about the governance output itself violating the rules of the constitution, for which article 3.4.4 makes an exception.
I'm curious how others interpret it!
2) I just noticed that in the Constitution 4.1, 4.2.3 (d) lists it as Progress Updates instead of Project, and it allows sharing updates on Accountabilities as well. How exactly is this facilitated? Should we ask for updates on the Projects listed in GlassFrog, and also ask each individual if they want to share any other updates on Projects or Accountabilities?
The best practice I can think of is to treat "accountability updates" just like project updates: no need to ask about *each* accountability, just like there's no need to report on *all* the projects you're working on. Let the circle member report on the ones that make sense to them, and allow other circle members to request updates about specific accountabilities on an as-needed basis.
GlassFrog isn't quite adapted to track accountabilities like it is with projects, but you could use the project board to track accountabilities anyway. We haven't done it (yet) at H1 for whatever reason (probably because few people noticed that possibility!), but that's how I would facilitate it.
Off the top of my mind, I see two main reasons why it makes sense to limit those duties to circle members.
- Circle boundary: the limitation to circle members reflects the circle boundaries, so in that sense it's consistent with the overall ruleset. If you want to request something from the member of another circle, you may have to go through the "proper channel", e.g. through the Rep Link etc.
- Overwhelm: imagine if even only 5% of an organization of 10,000 people contacts you directly to engage you in your circle member duties, it would quickly become unmanageable...! Given that one of those duties ("processing over execution") is to process inbound messages over executing on your actions, you might never get any work done.
EDIT: that said, even if it's not a constitutional duty, people use their judgement and if they want to process inbound from other circle roles, they are welcome to. That's what we do in 99% of the cases at HolacracyOne too.
Hope that helps!