새로운 기능과 기존 기능 변경 사항을 관리하는 시스템 'Upcoming Changes' 소개

[lindsey (Lindsey Fogle)]

Discourse를 지속적으로 개선해 나가는 과정에서, 관리자분들이 Discourse에 어떤 변경 사항이 적용될지 이해하고, 해당 변경 사항이 커뮤니티에 어떻게 구현되는지 관리할 수 있도록 돕기 위해 새로운 ‘예정된 변경 사항(Upcoming Changes)’ 설정 페이지를 만들었습니다. 이 시스템이 Discourse를 안전하고 투명한 방식으로 지속적으로 개선하는 데 도움이 될 것이라고 믿습니다.

이 주제(topic)에서는 이 새로운 시스템이 어떻게 작동하는지, 그리고 커뮤니티에 새로운 기능과 기타 변경 사항을 안전하게 도입하는 데 이를 어떻게 활용할 수 있는지 설명드리겠습니다.

예정된 변경 사항(Upcoming Changes) 작동 방식 개요

새로운 기능이나 기타 변경 사항을 개발하는 동안, 해당 항목을 /admin/config/upcoming-changes의 ‘예정된 변경 사항’ 설정 페이지에 추가합니다. 각 변경 사항은 설명, 상태, 어떤 사용자에게 영향을 미치는지 여부, 그리고 커뮤니티 내에서 해당 변경 사항이 활성화된 사용자(있다면)를 나타내는 정보를 포함합니다.

변경 사항의 상태에 따라 커뮤니티를 위해 이를 켜거나 끌지 여부를 결정할 수 있습니다. 다만, 일부 변경 사항은 결국 영구적으로 켜지게 되므로 적어도 일시적으로는 그렇게 할 수 있습니다.

변경 사항을 일시적으로 비활성화하면, 영향을 받는 사이트 커스터마이징, 프로세스 등을 처리하거나, 회원들에게 변경 사항을 알리거나, 특정 회원 그룹을 테스트용으로 지정하는 데 시간을 벌 수 있습니다.

예정된 변경 사항 분석하기

예정된 변경 사항을 하나 살펴보고, 각 섹션에서 볼 수 있는 정보를 정의해 보겠습니다.

1 - 이름 및 설명

이름과 설명은 변경 사항에 대한 간략한 설명을 제공하며, 추가 정보와 피드백을 수집할 수 있는 관련 메타(Meta) 주제(topic)로 링크됩니다.

2 - 상태(Status)

상태는 개발 라이프사이클에서의 위치를 나타냅니다. 상태는 해당 변경 사항이 옵트인(기본적으로 꺼져 있지만 켤 수 있음), 옵트아웃(기본적으로 켜져 있지만 끌 수 있음), 또는 강제 활성화(켜져 있으며 끌 수 없음)인지를 직접적으로 결정합니다.

'예정된 변경 사항’에서는 다음 상태를 사용합니다:

• Experimental(실험적): 초기 개발/테스트 단계에 있는 잠재적 변경 사항으로, 빠르게 진화하거나 실험이 종료되면 완전히 제거될 수 있습니다(이 경우 Inactive 상태로 전환됩니다. 아래 참조). Experimental 변경 사항에 옵트인하여 테스트해 볼 수 있습니다.
• Alpha(알파): 사용해도 안전한 테스트가 완료된 변경 사항이지만, 디자인이나 기능에 일부 소규모 업데이트가 있을 수 있습니다. Alpha 변경 사항에 옵트인하여 조기 사용할 수 있습니다.
• Beta(베타): 사용해도 안전한 테스트가 완료된 변경 사항으로, Stable 또는 Permanent 상태로 전환되기 전에 크게 변경될 가능성은 낮습니다.
  • 저희 호스팅을 사용하는 대부분의 사이트와 셀프 호스팅 사이트의 경우, Beta 변경 사항은 모두에게 자동으로 켜집니다(이전에 활성화하지 않은 경우), 하지만 여전히 옵트아웃할 수 있습니다.
• Stable(안정적): 완료된 변경 사항^[1], 하지만 여전히 옵트아웃(관리자가 비활성화 가능) 상태입니다. Stable 변경 사항에 옵트아웃한 경우, 관리자는 대시보드에서 경고 메시지를 받게 됩니다.
• Permanent(영구적): 테스트가 완료된 변경 사항으로, 강제 활성화(관리자가 비활성화 불가) 상태입니다. 영구적 변경 사항은 더 이상 예정된 변경 사항 목록에 표시되지 않으며, 대신 /admin/whats-new 페이지에 표시됩니다.
• Inactive(비활성): 중단된 실험입니다. 옵트인할 수 없습니다.

가끔 변경 사항은 이러한 상태를 선형적으로 통과합니다(예: Experimental로 시작하여 Permanent로 종료), 하지만 항상 그런 것은 아닙니다. 일부 변경 사항은 Alpha 또는 Beta 상태로 도입되며, 일부는 Stable 상태로 종료됩니다. “사이트 설정 기본값” 유형의 변경 사항은 기존 설정의 기본값만 변경하기 때문에 Permanent 상태로 전환되지 않습니다.

특정 변경 사항이 한 상태에서 다른 상태로 전환되는 데 걸리는 시간은 정해져 있지 않지만, 다음과 같은 경우 관리자에게 알림이 전송됩니다:

• 새로운 변경 사항이 테스트 가능해졌을 때
  • 알림 피로감을 방지하기 위해 주 1회 이하로 전송됩니다. 이러한 알림을 수신하고 싶지 않다면 /my/preferences/notifications에서 비활성화할 수 있습니다.
• 변경 사항이 자동으로 활성화되었을 때
• 곧 강제 활성화될 변경 사항을 비활성화했을 때
  • 이는 관리자 대시보드 경고로 표시됩니다.

3 - 영향 받는 사용자(Impacted users)

영향 받는 사용자 태그는 커뮤니티 내에서 어떤 사용자가 해당 변경 사항을 어떤 방식으로 보거나 상호작용할 수 있는지를 설명합니다. 쉽게 말해, 누가 이 변경 사항을 인지할 수 있는가? 영향 받는 사용자의 유형은 다음과 같습니다:

• Admins(관리자): 변경 사항이 관리자만 볼 수 있습니다.
• Staff(스태프): 변경 사항이 관리자 및 모더레이터만 볼 수 있습니다.
• All members(모든 회원): 변경 사항이 사이트의 모든 회원에게 표시됩니다.
• Developers(개발자): 드문 경우지만, 코어, 테마, 플러그인의 코드와 상호작용하는 사람만 변경 사항을 인지할 수 있습니다.

영향 유형(Impact type)

영향 받는 사용자의 하위 집합이며 목록에 표시되지 않는 것이 영향 유형입니다. 영향 유형은 변경 사항이 커뮤니티에 광범위한 의미로 어떤 영향을 미치는지를 설명합니다:

• Feature(기능): 커뮤니티에 새로운 기능이나 기능을 도입하거나 기존 기능을 수정합니다.
• Site setting default(사이트 설정 기본값): 기존 사이트 설정의 기본값을 수정합니다. 이미 설정을 이전 기본값에서 변경한 관리자는 영향을 받지 않습니다. 이 변경 사항이 Stable 상태에 도달하면 관리자 대시보드 경고가 표시되지 않습니다.
• Other(기타): 위의 카테고리에 해당하지 않는 기타 모든 변경 사항.

4 - 활성화 대상(Enabled for…)

이 드롭다운은 사이트 관리자로서 이 변경 사항을 커뮤니티에 언제, 어떻게 도입할지 활성화 대상을 지정하여 제어할 수 있는 곳입니다:

• No one(아무도): 사이트의 모든 사람에게 변경 사항을 비활성화합니다.
• Everyone(모두): 사이트의 모든 사람, 익명 사용자를 포함하여 변경 사항을 활성화합니다. 변경 사항이 자동으로 켜질 때(보통 Beta 상태일 때), 대상은 Everyone이 됩니다.
• Staff only(스태프만): 사이트 스태프(즉, 관리자와 모더레이터)에게만 변경 사항을 활성화합니다.
• Specific groups(특정 그룹): 선택한 그룹에게 변경 사항을 활성화합니다.

일부 예정된 변경 사항은 “활성화 대상” 옵션이 제한될 수 있습니다. “활성화 대상” 드롭다운의 사용 가능한 옵션은 변경 사항의 구성에 의해 결정됩니다. 예를 들어, 제한된 그룹 테스트가 불가능한 변경 사항의 경우 Everyone과 No one 옵션만 허용될 수 있습니다.

---

현재 /admin/config/experimental의 대부분의 Experimental 변경 사항을 '예정된 변경 사항’으로 이동했으며, 곧 새로운 업데이트가 여기에 반영되기 시작할 것입니다. 이 변경 사항이 커뮤니티에 미칠 영향에 대한 의견을 듣고 싶으며, 질문이나 피드백을 환영합니다!

---

1. 소프트웨어가 완결된다는 것은 어디까지나! ↩︎

[NateDhaliwal]

I’m curious - how does it control how the change is rolled out? Can it be changed after the feature is introduced? Thanks.

[merefield (Robert)]

Native Feature Flags! Very good

Be great to have an API for plugins.

[Canapin (Coin-coin le Canapin)]

That’s a long-awaited feature! Thanks!

[darkpixlz (Pyx)]

This is great, having the ability to change flags like this is amazing for people on the bleeding edge like myself especially when developing a theme

Is “upcoming changes” really the best name for it though? For example HomeAssistant uses “labs” and a lot of other people just use stuff like “experiments” which feel better than upcoming changes.

[lindsey (Lindsey Fogle)]

@NateDhaliwal

I’m curious - how does it control how the change is rolled out?

You’ll be notified of new features while they are still in a state where you can try it out early (opt-in) and turn it off temporarily to fix any issues caused by the change (opt-out). If a change is going to become permanent (which means you can’t opt-out) and you’ve currently turned it off, we’ll let you know.

This section describes that in a little more detail:

@lindsey

Sometimes, changes will move linearly through these statuses (i.e. start in Experimental and end in Permanent), but not always. Some changes may be introduced in Alpha or Beta status, and some will end in Stable status (if they will not be forced on).

There is no set time for how long it will take a particular change to progress from one status to another, but admins will be notified when:

• A new change is available to try out
• A change has been enabled automatically
• When you have disabled a change that will soon be forced on

@darkpixlz

Is “upcoming changes” really the best name for it though?

Right now, you’re seeing only experimental changes because we migrated those over from the settings area to Upcoming Changes, but in the future there will be non-experimental updates here, too. So “labs” doesn’t feel accurate for how we are using this system.

[martin (Martin Brennan)]

@merefield

Be great to have an API for plugins.

Plugins can already use this system. The OP doesn’t go into the technical ins-and-outs, but there is not much needed to add an upcoming change.

The quick summary is:

• Add a site setting which is hidden: true and client: true

• Add a description for the setting in server.en.yml

• Optionally add a screenshot to public/images/upcoming_changes/SETTING_NAME.png

• Add upcoming_change metadata to the setting, which looks like this:

# upcoming_change       - Additional metadata with the following options to show in the /admin/config/upcoming-changes page:
#                          - status: experimental | alpha | beta | stable
#                          - impact: two parts separated by comma - feature|other , staff|admins|moderators|all_members|developers
#                          - learn_more_url: a url for more information

However the caveat here is that we haven’t really intended to have third party plugin developers use this system, it was mostly for our own purposes. Maybe over time we can think more about this use case.

[noahl (Noah Lovell)]

Love this! Thank you

Is it possible to have a link/shortcut to the applicable setting if relevant? e.g. the custom splash screen has additional settings that need setting up for it to work (uploading the SVG) - but you have to actively go and find them. Would be helpful to have them alongside where it’s being enabled

[martin (Martin Brennan)]

Yes indeed! I’m working on that change now, should be available in the next day or two, I will make a note to deploy your hosted site so you get the update

Edit: Done!

[sniper756]

I have a question, for a self-hosted Discourse instance, how do I display these “Upcoming Changes” in the admin panel?

@lindsey

[martin (Martin Brennan)]

We still have this hidden behind a global enable_upcoming_changes site setting which is hidden, so you can enable this in your site’s rails console with rails c. Eventually we will remove this and you won’t have to anymore.

[sniper756]

Okay, thank you, I’ll wait then~

[ToddZ]

I’m not sure if this was clear: the menu item for Upcoming Changes isn’t live yet, but …

rephrasing:
If you don’t have the menu item yet, you can still see the Upcoming Changes section by going to [your_forum]/admin/config/upcoming-changes

[martin (Martin Brennan)]

It should be, you don’t see it here?

Are you self-hosting? If so you will also need to set enable_upcoming_changes (which is a hidden setting) to true. We plan to remove this in the not-too-distant future once we are completely sure the system is stable.

[Moin]

Is there a reason why most site settings for upcoming changes are hidden, but enable_auto_grid_images is not?

[martin (Martin Brennan)]

@Moin

enable_auto_grid_images

Nope, just an oversight, fixed here:

FIX: Hide enable_auto_grid_images site setting (#38046)

[ToddZ]

Yes, I’m self-hosting, like sniper756.
“isn’t live yet” was maybe not the best phrasing; I’ll edit.

[Moin]

오늘은 변경 사항을 상태로 정렬할 수 있으면 편리할 것 같다는 생각을 했어요. 먼저 베타, 그다음 알파, 마지막으로 실험적 단계 순서로요. 상태로 필터링하는 건 가능하다는 걸 알고 있지만, 전체 목록을 한눈에 보고 싶거든요. 상태에 따라 변경 사항이 더 흥미롭거나 덜 흥미롭다고 느껴지기 때문이에요.

[martin (Martin Brennan)]

네, 말이 되네요. 사이트에 변경 사항이 표시된 시점을 기준으로 정렬 옵션을 추가하는 것도 생각해 봤습니다… 두 가지를 모두 추가할게요

[khenmu (John Sweeney)]

훌륭한 추가입니다!

이것을 올려주셔서 감사합니다.