And you can help by spreading the word: mentioning these stories to friends among our community of site users, linking to these stories in your community Groups as a heads-up, republishing these stories to your active Groups for visibility among your membership, and encouraging community members to participate in the beta testing.
Thus far we have discussed the need to know your login credentials (all users will have to log in at the new site when we launch), the need for you to act now to preserve what can not be migrated, and changes to community moderation (Tip Jars, Mojo, Trusted User Status, reporting). Yesterday afternoon iterology provided an important timeline of the migration process and also updated the site banner on the Front Page to alert users that the site will be down starting on April 14.
Today we’ll note the changes to community Groups features and functionality.
ON THE NEW SITE THE NOMENCLATURE OF GROUP ROLES WILL BE DIFFERENT; THE SYSTEM FOR GROUP MESSAGING HAS BEEN REPLACED; INDIVIDUAL PUBLICATION TO A GROUP IS UNCHANGED (ADMINS AND EDITORS, IMMEDIATE OR SCHEDULED); INDIVIDUAL REPUBLICATION TO A GROUP IS UNCHANGED (ADMINS AND EDITORS); THE CURRENT APPROVAL QUEUE WILL NO LONGER EXIST
First, and please, don’t panic. We recognize how critically important community Groups are and we recognize that any changes to the features, functionality, and processes for Group publication, republication, and messaging are going to create anxiety. There was only one serious option for a plug-in available for the WordPress version of the site with which to duplicate much of the current Groups functionality. There are technical constraints: customizing that plug-in has proven more challenging and more time-consuming than anticipated.
Much of the current functionality of community Groups will be available at launch on the new version of the site. Some functionality will not be available. To guide this discussion of changes to Groups functionality, we are including a chart for comparison and we’ll then outline changes for “typical” users and roles within Groups, noting the special use-cases for which there will not be a direct equivalent and proposing workarounds.
First up, however, the change in nomenclature for roles within Groups. In place of the current three roles (Administrators, Editors, Contributors), the migrated equivalents in BuddyPress will be Administrators, Moderators, and Members. That should help make sense of the comparison chart below (open image in a new Tab to enlarge, if necessary, or view the full-size image here):
Chart comparing group features
These are the permissions by Group role in the new version of community Groups.
Group Administrators — can manage the Group’s profile page; can manage Group membership (promote, demote, delete, ban); can invite users to join the Group and process invitations and requests to join; can send and read messages on the Group’s private Activity Tab, and can delete any/all Group messages on the Group’s Activity Tab; can immediately publish a self-authored story to the Group; can schedule a self-authored story to publish to the Group at a later time; can immediately republish (reblog) a story authored by any other user to the Group’s Stories Tab
Group Moderators (formerly Editors) — at the discretion of a Group Administrator, there is a setting to enable Group Moderators to invite users the join the Group and process invitations and requests to join; can send and read messages on the Group’s private Activity Tab, and can delete any/all Group messages on the Group’s Activity Tab; can immediately publish a self-authored story to the Group; can schedule a self-authored story to publish to the Group at a later time; can immediately republish (reblog) a story authored by any other user to the Group’s Stories Tab
Group Members (formerly Contributors) — can send and read Group messages on the Group’s Activity Tab, can delete only their own messages on the Group’s Activity Tab
We realize that there are some significant changes to the functionality of Community Groups by Group role, and most of those changes are the result of the absence of an equivalent approval queue. These changes may have little impact on some Groups, depending on the membership composition of the Group and its typical workflow, but we absolutely recognize that they may have serious impact on other Groups’ workflows, most especially for Groups that have relied on the approval queue for shared editing of queued draft stories.
We also have the implementation of an equivalent “Remove from Group Feed” tool backlogged with medium priority.
Here then are the changes in outline, by Group role and publication/republication task. We ask you to think of the Groups you are in, with what current role, how you are accustomed to publishing/republishing (reblogging) within your Groups, and identify what will change for you.
Group Administrator (migrated Group Administrators)
YES — publish immediately a self-authored story directly to the Group, acquiring the “by [username] for [Group name]” byline
YES — schedule and publish a self-authored story directly to the Group, acquiring the “by [username] for [Group name]” byline
NO — queue a self-authored story draft to the Group approval queue for shared editing (currently by Admins and Editors) and delayed publication from the queue, acquiring the “by [username] for Group name]” byline
YES — republish (reblog) immediately a story authored by another user to the Group’s Stories Tab, and the story is assigned the “[Group name] Republished” notation
NO — republish (reblog) to the Group approval queue a story authored by another user, for deliberation (currently by Admins and Editors) whether to republish the story later and assign the “[Group name] Republished” notation
Group Moderator (migrated Group Editors)
YES — publish immediately a self-authored story directly to the Group, acquiring the “by [username] for [Group name]” byline
YES — schedule and publish a self-authored story directly to the Group, acquiring the “by [username] for [Group name]” byline
NO — queue a self-authored story draft to the Group approval queue for shared editing (currently by Admins and Editors) and delayed publication from the queue, acquiring the “by [username] for Group name]” byline
YES — republish (reblog) immediately a story authored by another user to the Group’s Stories Tab, and the story is assigned the “[Group name] Republished” notation
NO — republish (reblog) to the Group approval queue a story authored by another user, for deliberation (currently by Admins and Editors) whether to republish the story later and assign the “[Group name] Republished” notation
Group Member (migrated Group Contributors)
NO — queue a self-authored story draft to the Group approval queue for approval, shared editing (currently by Admins and Editors), and delayed publication from the queue, acquiring the “by [username] for Group name]” byline
NO — republish (reblog) to the Group approval queue a story authored by another user, for deliberation (currently by Admins and Editors) whether to republish the story later and assign the “[Group name] Republished” notation
The absence of an approval queue will have little impact on Groups in which direct or scheduled publication by Admins and Editors are the norm. It will have an impact on Groups who rely on the approval queue for shared editing of queued drafts or who have a significant number of Contributors who regularly queue content for possible publication or republication. One method to address the latter circumstance is for Group Administrators to consider promoting reliably judicious users from Member to Moderator, giving them access to the direct publication and republication options. Alternatively, Members will have access to the Group’s private Activity Tab and can suggest stories for republication in messages there.
To the current Administrators and Editors of Groups with a regular workflow relying heavily on the approval queue for shared editing and scheduling of draft stories: we recognize that these changes willl hit you hardest.
Here’s what we ask. Think about the form of shared editing you need. If it is primarily “final touches” of formatting (inserting a Group image, or boilerplate text in a header or footer, etc.), can those formatting elements be shared in a way that the author could access them, format on their own, and shift to scheduling publication of their own draft story directly to the Group? If an author has already published their story, and the Group is considering republication, can text editing notes be shared in direct messages so that the author can make suggested edits in their own story and then the Group can republish it?
Honestly, what we ask and hope most of all is that all current Group Administrators and Editors will create a user account on the beta site, use that account to create and join Groups there in different roles, apply your creativity in problem-solving, and post stories (here and on beta) sharing workable strategies with Administrators and Editors of other Groups. It is amazing to see how many of you are already playing in the beta sandbox, raising issues, proposing workarounds, and assisting each other.
One other option also exists, which is for a Group Administrator to create a single new user account with shared login credentials so that multiple Administrators and Moderators would have access to a single user account, able to log into that account separately to edit and schedule the story within the shared user account’s drafts. We’re willing to overlook the prohibition on multiple simultaneous accounts for this specific purpose, since it’s obvious that no skulduggery is intended (unlike malevolent sockpuppets). We do recognize however that this option may place an uncomfortable burden on Group leadership since they will have to consider how widely to draw that “circle of trust” for shared access to that user account. All of that said, it’s worth noting as an example of this option that the user account Black Kos has been shared successfully to create co-edited content for the Black Kos Community Group for some time. At least one other Community Advisory Panelist has also been experimenting with implementing this option on beta already, and may be willing to share their thoughts in comments here.
If necessary, once the Administrators and other leaders of significantly impaced Groups have created accounts and Groups on the beta site and have tested functionality to attain a better hands-on understanding of what is available, we are also quite willing to host a virtual “summit” or two to share thoughts, ideas, and solutions.
P.S.: for those of you who will participate in beta testing, please note that use of the beta site involves creating a new account for use ONLY at the beta site, and that account (and associated content and Groups) will exist ONLY for the duration of the beta testing. The username, email address of record, and password for an account on the beta site are independent from your existing account here, and beta accounts will not be migrated to the new version of the site.
