At my organization, we often add the same sets of users
to nosy lists for certain types of issues.  We've
implemented a new feature that places groups, not
individual users, on the nosy list.

To do this we have:
- Created a new Group class, with properties groupname,
description, and members.  Members is a multilink to
the User class.

- Replaced the nosy field in the Issue class with a new
field, nosygroup, consisting of a multilink to Group.

- On the issue.item template, the "Nosy Lists" text box
now displays the contents of this new field.

- New group.index and group.item templates are created.

- The nosyreaction detector and the roundupdb code that
sends out emails is modified to reflect this.  If a
user is in more than one group in the nosygroup list,
they still get only one email.

One hitch was that the existing code automatically
added the assignedto user and message recipients to the
nosy list.  We got around this by creating single-user
groups, one for each user, with the groupname matching
the username.  These are added when the corresponding
user is placed in the assignedto field, or a message
sent to them.

This is a bit of a hack.  The way to make it "proper"
would be to make the single-user groups unmodifiable
without modifying the corresponding user (i.e. they
exist solely behind the scenes).  Alternatively, we
could show both nosy-individual and nosy-group fields
in the user interface, but this seems a bit cluttered.

If this design seems appropriate, we can submit a patch
containing the code changes we made.