# Improved Group Members Management

**URL:** https://meta.discourse.org/t/improved-group-members-management/16768
**Category:** Feature
**Tags:** rfc, spec
**Created:** [6월 22, 2014, 2:28오후 UTC](https://meta.discourse.org/t/improved-group-members-management/16768 "2014-06-22T14:28:23Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![jmay](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jmay/32/108427_2.png) [@jmay](https://meta.discourse.org/u/jmay)
#### Post date: [11월 20, 2014, 9:08오후 UTC](https://meta.discourse.org/t/improved-group-members-management/16768/11 "2014-11-20T21:08:06Z")

</div>

Reviving this feature conversation.

Group administration is troublesome when the group is large. The  
client currently sends the entire updated membership list to the  
server whenever there are any changes, and the server has to figure  
out what has changed.

I propose:

- paginated viewing for group membership
- incremental adds and deletes for group membership

This is to set the stage for a new “group owner” role that can be  
designated on a per-group basis.

A group owner should be able to add and remove members from any group  
over which they have ownership.

Group owner should _not_ be able to change:

- group name
- visibility setting
- alias levels

These functions should remain restricted to administrators.

I suggest that the existing public group membership page  
(`/groups/{group-name}/members`) be extended for this purpose. The  
existing group admin page (under `/admin/groups`) will remain  
available only to staff.

First step is to update the group membership UI, but restrict the  
editing features to staff. Once the UI is settled, add the group owner  
role.

---

_[View the full topic](https://meta.discourse.org/t/improved-group-members-management/16768)._