![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
Separate list of subscribers and people who give access
Title:
Separate list of subscribers and people who give access
Area:
circle management
Summary:
Separate out the people on your manage circle page so that people who have subscribed or given access to you (but who you do not subscribe to or give access to back) appear in a separate section or page.
Description:
Currently, on the manage subscription page all people who have subscribed and given access to you appear in the same list as those who you have given access and subscribed too. While in many cases access and subscription is mutual, it is not always - and at times this can make sorting through the people in your circle difficult if you are just trying to focus on those people that you have added to your circle. This is even more difficult if you have a large number of subscribers that you don't subscribe back to.
To use an example from LiveJournal, there I have a journal which has been friended by 237 journals that I do not have friended back. This naturally made managing my friends list for that particular journal very difficult, as I would need to wade through large numbers of people that I didn't have friended in order to manage the ones that I did.
Putting journals that have added you to their circle but who you have not added back would allow people to be able to focus specifically on those journals that you specifically have added to your own journal. Implementing should hopefully be relatively simple, as those journals could go in a separate list much like how communities are listed separate on the manage friends page. An alternate solution might also be to have an option to sort the users you have added by particular criteria (such as 'view all' and 'view only your subscriptions' and 'view only who you give access to', although this might involve more complicated coding.
This suggestion:
Should be implemented as-is.
26 (54.2%)
Should be implemented with changes. (please comment)
7 (14.6%)
Shouldn't be implemented.
2 (4.2%)
(I have no opinion)
12 (25.0%)
(Other: please comment)
1 (2.1%)