추상 위키백과/업데이트/2023-02-08

추상 위키백과 업데이트

Google.org 동료의 평가에 대한 추가 의견

펠로우쉽 동안 Google.org 펠로우들은 위키함수 및 추상 위키백과 프로젝트에 대한 자세한 통찰력을 얻었습니다. 잠재적인 문제를 지적하고 일부 프로젝트 접근 방식에 대한 잠재적 대안을 논의하기 위해 그들은 위키함수 및 추상 위키백과 프로젝트에 대한 자세한 평가를 작성했습니다. 팀은 평가를 읽고 자세한 답변을 작성했습니다. 12월에 전체 문서를 게시했습니다:

더 사인포스트는 평가에 대해 보도했으며 팟캐스트 괄호 사이의 에피소드에서 무엇보다도 이에 대해 논의했습니다. 오늘 우리는 문서에 대한 요약을 제공하고 너무 기술적인 요약은 하지 않으려고 합니다. 문서는 길고 기술적이었습니다. 우리는 40페이지 토론의 2페이지 요약이 필연적으로 단순화되고 많은 뉘앙스를 훑어볼 수 있다는 것을 이해하지만, 세부 사항에 뛰어들고자 하는 모든 사람을 위해 전체 문서를 사용할 수 있습니다.

평가는 프로젝트를 변경하기 위한 많은 제안과 제안을 설명하고 8개의 전면적인 권장 사항으로 끝납니다. 우리는 평가에서 제시된 많은 제안을 받아들였습니다. 일부는 이미 구현되었고 다른 일부는 프로젝트 작업 보드의 작업이며 구현을 기다리고 있습니다.

의견 불일치의 주요 영역은 마지막 8개 권장 사항에 있습니다. 요약하면, 권장 사항은 재단이 위키함수와 추상 위키백과를 별도의 프로젝트로 취급해야 한다고 제안합니다. 또한 두 프로젝트의 범위를 대폭 좁힐 것을 권장합니다.

위키함수의 경우 평가에서는 다국어 사용자 인터페이스가 기반이 되는 함수 모델을 삭제할 것을 권장합니다. 또한 비개발자가 함수를 제공할 수 있도록 하는 기능을 제거하고 여러 언어를 허용하는 대신 단일 프로그래밍 언어인 루아에 집중할 것을 권장합니다.

추상 위키백의 경우 평가에서는 커뮤니티와 함께 하나 이상의 자연어 생성 솔루션을 공동 생성한다는 아이디어를 삭제하고 기존 자연어 생성 시스템을 선택하도록 제안합니다. 또는 펠로우십 중에 펠로우 중 한 명이 제안한 것을 채택합니다. 커뮤니티가 솔루션을 실험하고 개발할 수 있도록 하는 다목적 기능 저장소를 만드는 대신, 권장 사항은 프로젝트 팀이 편집자의 기여를 통합하는 위키 외부 시스템이 될 단일 솔루션을 결정하고 하드 코딩하는 것입니다.

이것은 매우 유사한 제안에 직면한 위키데이터에 대한 초기 비판과 유사합니다. 기존 온톨로지를 선택하거나 온톨로지 팀을 고용하는 대신 커뮤니티가 위키데이터의 온톨로지를 만들고 유지하도록 허용하는 결정이 둠 위키데이터. 우리는 그 결정을 고수했기 때문에 일부 주요 자금을 잃었습니다.

추상 위키백과 및 위키함수의 개발 팀은 두 권장 사항 집합을 모두 거부했습니다.

일부 거부에 대한 한 가지 간단한 이유는 평가가 실제로 현재 개발 상태가 아니라 “기술 계획”을 평가했기 때문입니다. 예를 들어 한 가지 권장 사항은 다른 프로그래밍 언어를 허용하는 대신 루아에만 집중하는 것입니다. 후자는 구현하는 데 오랜 시간이 걸리기 때문입니다. 그러나 “이미 해당 기능을 구현”한 경우 권장 사항을 채택하면 속도가 느려지고 이미 완료된 작업을 폐기하게 됩니다.

권장 사항에 대한 일부 거부는 위키미디어 값을 기반으로 합니다. 우리는 사람들이 자신의 자연어로 기여하고 사용할 수 있는 프로젝트를 갖는 것이 중요하다고 생각합니다. 우리는 프로그래머가 아닌 사람들이 기여할 수 있도록 하는 것이 중요하다고 생각합니다. 다양성을 위해서만이 아니라 단순히 관련 기술을 가진 잠재적 기여자 풀이 많은 언어 커뮤니티에서 매우 제한적이기 때문입니다. 여러 언어로 자연어 생성 기능을 만들고 유지 관리할 사람이 필요합니다. 기여할 수 있는 더 넓은 기술 집합을 허용하면 이러한 잠재적인 병목 현상이 줄어듭니다. 이것이 추상 위키백과에 위키함수가 필요한 이유이며, 동시에 위키함수는 추상 위키백과의 사용 사례로 이점을 얻습니다. 공생 관계입니다.

위키미디어 운동이 이미 하고 있는 것처럼 현재 300개 언어를 다루는 상징적인 자연어 생성 시스템은 없습니다. 우리는 기존 솔루션이나 펠로우십 중에 개발된 새로운 솔루션을 자신 있게 선택할 수 없습니다. 실제로 남아공 케이프타운 대학교의 마리아 키트 교수는 자원봉사자로 추상 위키백과 개발에 참여했습니다. 그녀는 기존의 인기 있는 자연어 생성 시스템과 펠로우십 중에 생성된 시스템 모두 니제르 콩고 B 언어와 잘 작동하지 않는다는 점을 비판했습니다. 동료의 제안은 그러한 언어의 요구를 더 잘 지원하기 위해 업데이트되었습니다. 우리 아키텍처가 외부 자연어 생성 시스템과 밀접하게 연결되어 있지 않기 때문에 이렇게 할 수 있었습니다.

우리는 아직 구현되지 않은 언어가 주어진 시스템의 주요 문제가 될 기능을 가지고 있는지 여부를 알 수 없으며 대부분 알 수 없습니다. 범용적이고 유연한 시스템에서 커뮤니티는 그러한 문제를 해결할 수 있는 권한을 갖게 됩니다. 단일 솔루션을 선택하면 문제 해결에 대한 장벽이 상당히 높아집니다. 위키에 기여하는 대신 SimpleNLG의 경우 git을 통해 업스트림 자바 프로젝트에, 문법 프레임워크의 경우에는 Haskell로 작성된 프로젝트에 기여하는 등 다른 곳에서 기여하는 개발자가 필요합니다. 그리고 최악의 경우, 그러한 결정으로 인해 가장 불리한 영향을 받을 가능성이 가장 높은 커뮤니티는 이미 과소 대표되는 커뮤니티일 것입니다.

우리는 기존의 자연어 생성 시스템을 사용하는 것을 반대하지 않습니다. 우리는 기존 솔루션을 활용하여 커뮤니티를 지원할 것이며 이미 지원하고 있습니다(우리는 동료들이 강력히 권장하는 문법 프레임워크와 긴밀히 협력하고 있습니다). 그러나 이 시점에서 우리는 기존 솔루션 중 어느 하나에 독점적으로 전념하지 않을 것입니다. 대신 계획은 처음부터 커뮤니티가 접근 방식을 구축, 유지 및 소유하고 커뮤니티가 사용 가능한 솔루션을 사용 및 결합하고 커뮤니티와 함께 추상 위키백과를 공동 생성할 수 있도록 하는 것이었습니다.

8가지 권장 사항과 결정에 대한 이 요약이 우리가 만들고 있는 것과 결정을 내린 이유를 이해하는 데 도움이 되기를 바랍니다.

개선할 프로세스의 좋은 이름은 무엇입니까?

파이썬에는 PEP(Python Enhancement Proposal), 자바에는 JSR(Java Specification Request)이 있고 많은 위키에는 [wikidata:Q4654740 RfC](Request for Comment, IETF에서 영감을 받음) 또는 이와 유사한 용어가 있습니다. 위키함수는 출시 후 잘 개선될 것이며 위키, 메일링 리스트 또는 파브리케이터에서 이러한 개선 사항을 논의하는 프로세스가 필요합니다. 이 프로세스에는 이름이 필요합니다!

우리는 큰 투표를 하지 않을 것이지만, 이름에 대한 아이디어와 선호 사항이나 우려 사항이 있는지 묻고 싶습니다. 일부 내부 제안은

커뮤니티 시스템 변경(CSC)
리틀 람다 채팅(LLC)
생각할 거리(FFT)
위키함수 람다 델타(WILD)
위키함수 시스템 컨설팅(WSC)
함수 모델 제안(FMP)

또한 공식 위키함수 모델의 초기 변경 프로세스를 실행하고 구조화하는 방법에 대한 제안이 있는 경우 알려주십시오. 우리는 이것이 시간이 지남에 따라 상당히 변할 것으로 예상하지만, 우리가 일할 수 있는 많은 경험이 있을 것입니다.

2023년 2월 3일 주간 개발 업데이트

지난 주에 우리는 버그를 수정하고 기술 부채를 상환하는 데 초점을 맞춘 가벼운 회의 주간인 2개월 수정 주간을 가졌습니다. 수행된 작업의 몇 가지 예는 다음과 같습니다:

작은 버그 수정, 예. fixWidth 문제 또는 불필요한 검사 제거
테스트 범위 개선, 예: 직렬 변환기 또는 문자열 구성 요소에서 일시적으로 비활성화된 테스트를 다시 활성화합니다. 빈 목록 매핑용
구성 요소 및 기능의 이름을 보다 명확하고 일관되게 변경, 예를 들어 '일반 오류'의 이름을 '지정되지 않은 오류'로 바꾸거나 구성 요소에 접두사를 추가합니다.
리팩토링, 예. 전체 디렉토리 재구성, 메타데이터 대화 상자를 단일 구성 요소로 통합 또는 기존 함수 일반화
구성 요소를 보다 현대적인 구성 요소로 교체합니다. 예를 들어, 코덱스에서 가져온 우리만의 '칩'