Talk:Growth/Community Configuration

We are working on project to allow communities to manage the configuration of the Growth features on their own. In the past, communities have needed to work directly with the Growth team to set up and alter the features. We plan to put this capability in the hands of administrators, through an easy-to-use form, so that the features can be easily tailored to fit the needs of each community.

Please share your thoughts here!

• Will communities develop consensus before making changes, or will individuals make changes unilaterally?

  I don't know the current process for getting community consensus while developing or right before releasing a feature, but ostensibly the interest/buy-in would come well before it's ready, if not from the feature's inception. As for comconfig itself, the answer is usually that individuals (admins) will make changes unilaterally until it becomes a problem for other users. When multiple users are invested in the outcome, they will create a process of how to make changes: by consensus of the editors involved and, if needed, soliciting a larger request for comments from a larger editor pool. Either way, the community handles it itself, though this should be raised a consideration a community will need to consider when discussing potential implementation.

• Will restricting the editing to administrators and interface admins be the right level of restriction?

  Yep. But on tiny Wikipedias, I wouldn't be surprised if you received a request for a different user level to have access. Even still, I think "admin" is a fine line to draw in terms of community trust.

• Will we need some kind of delay before configuration changes are made, so that a quick series of changes (or edit war on the form) don't cause a very disruptive experience for newcomers?

  Nope. I'd anticipate this to be a low traffic page. If there is a user-level block done on this page, there might be more activity but the worse case scenario there is edit conflicts, not a disruptive experience for newcomers. This said, when a user is restricted from the feature, whether in specific or removed altogether, you'll want some kind of visual feedback so they aren't looking at the hole where the feature once was and wondering whether they're hallucinating.

I think restricting configuration editing to administrators and interface administrators is fine. I think restricting to intadmins would be too much right now; I view the use case for intadmin restriction being execution of code on other machines which I don't believe is the case here. This seems similar to other site configurations we allow any administrator to edit. If things change or it turns out local admins are making a lot of bad decisions, then maybe further restriction is worthwhile, but as it stands the permissions seem fine.

Hi @Wugapodes -- thanks for checking this capability out, and letting us know that it seems on the right track.