Partkeepr: 파트키퍼 위키

지금은 내가 "작동"할 수 있었던 유일한 방법은 Google의 캐시된 페이지를 사용하는 것입니다. 관련 Wiki 페이지를 검색하기만 하면 Google에서 결과를 표시하고 링크 자체를 클릭하는 대신 링크 옆에 있는 작은 아래쪽 화살표를 클릭한 다음 캐시됨을 클릭합니다. 스타일은 없지만 내용은 있습니다. 또는 archive.org를 사용하여 이동합니다. http://web.archive.org/web/20180310044536/http://wiki.partkeepr . org:80/wiki/Main_Page

github의 폴더(또는 여기의 wiki 탭)에 있는 베어 html일지라도 언젠가는 Wiki가 다시 돌아오기를 바랍니다.

위키가 다시 온라인 상태가 된 것 같습니다.

좋은 소식입니다! 폐쇄.

어쨌든 위키가 호스팅되는 곳을 아는 사람이 있습니까? 이것은 여전히 ​​@Drachenkaetzchen의 책임입니까? 또 다른 문제 에서는 Partkeepr의 문제가 현재 약간 고착되어 있다고 설명합니다. @Drachenkaetzchen 을 돕고 다른 어깨에 책임을 지는 좋은 방법이 될 수 있습니다. 그런 다음 Wiki/SQL의 백업이 필요합니다.

@Gasman2014 전반적으로 이 문제가 장기적으로 해결될 때까지 다시 열도록 투표하겠습니다.

저는 @christianlupus 와 함께 있습니다. 대신 githubs의 wiki 섹션에서 호스트한다고 말하고 싶습니다. 그러면 @Drachenkaetzchen의 서버와 어깨에서 약간의 부하가 줄어듭니다 .

장기적 솔루션의 바람직함과 Felicia @Drachenkaetzchen 을 지원하려는 @C44Supra 및 @christianlupus 의 제안을 고려 하여 이 데이터를 보관하고 github를 통해 독립적으로 호스팅하여 이 데이터를 다시 엽니다. Wiki의 정보는 설치 문제를 해결하는 데 매우 유용합니다. 특히 기본 설정 가이드에 설명되지 않은 틈새 상황에서 그렇습니다. 이 정보는 최대한의 유용성을 위해 코드베이스와 함께 사용할 수 있어야 합니다. Wiki가 복원된 것을 보니 매우 기쁩니다. 그러나 도움이 되지만 추가적이며 다른 정보가 포함된 github wiki 섹션과 너무 많은 작업 없이 결합할 수 있을 것입니다.

누군가 호스팅된 Wiki를 GitHub로 자동으로 이동하는 방법을 제공할 수 있는 경우 실제로 그러한 메커니즘을 테스트한 경우에만 알려주세요. 간단한 구글은 그러한 메커니즘에 대한 많은 결과를 산출하며 나는 그것들을 조사할 시간이나 에너지가 없습니다.

현재 위키 또는 DB 덤프에 대한 API 액세스가 필요한 경우 알려주십시오.

나는 이것을 준비하기 위해 기꺼이 노력할 것입니다. 내 개인 계정에서 Wiki로 마이그레이션하려고 합니다. 내가 본 바로는 최신 버전의 Wiki만 마이그레이션할 수 있으며 일부 수동 조정이 필요합니다.

wiki 파일을 github으로 마이그레이션하려고 했습니다. 결과는 이 리포지토리 에서 볼 수 있습니다. 여전히 약간의 수정이 필요합니다(오타 제거, 페이지 이름 바꾸기, 파일 정리 등).

불행히도 XML로 자동 내보내기(미디어위키에서 내보내는 표준 방법)에는 몇 가지 단점이 있습니다. 이렇게 하면 페이지 기록이 손실되고 미디어 파일을 내보내지 않습니다. 수동으로 다운로드했지만 메타데이터(예: 제목 및 대체 텍스트)는 이식되지 않았습니다. 또한 github의 wiki는 Mediawiki보다 조금 더 제한적이어서 내가 아는 한 하위 페이지 목록이 불가능합니다.

@Drachenkaetzchen 위키를 이런 식으로 사용할 수 있는지 확인 부탁드립니다. 그런 다음 괜찮으면 Partkeepr 페이지에 있는 내 저장소의 페이지를 간단히 설치할 수 있습니다. 질문이 있는 경우 저에게 연락하십시오. 기꺼이 도와드리겠습니다.
추신: 나는 당신이 그것을 가지고 놀 수 있도록 당신을 리포지토리에 협력자로 추가했습니다.

다른 모든 사람들은 내가 놓친 오류를 찾기 위해 위키 헌팅을 살펴보는 것을 환영합니다.

@Drachenkaetzchen 위키를 이런 식으로 사용할 수 있는지 확인 부탁드립니다.

혼란스럽습니다. 정확히 무엇을 확인해야 하나요?

위키를 github에 이식했습니다. 이 작업이 귀하의 품질 표준에 따라 허용되는지 확인하고 완전히 엉망이되지 않았습니다.

나는 당신이 사용자에게 물어봐야한다고 생각합니다 ;) 나는 위키를 거의 사용하지 않습니다.

메일링 리스트에 대한 피드백을 요청하는 것이 좋습니다.

메일링 리스트 에 메시지를 남겼습니다. 완료를 위해서만 여기에서 상호 참조됩니다.

github wiki 대신 github Pages를 사용하는 것이 좋습니다. 파일 구성과 관련하여 더 많은 옵션이 있으며 두 솔루션 간에는 큰 차이가 없습니다. github wiki가 더 적합할 수 있는 옵션이 있습니까?

@Drachenkaetzchen 위키 마이그레이션과 관련하여 다른 사용자로부터 많은 관심과 응답을 받지 못했습니다. 일정이 있거나 여기에서 어떻게 진행할까요? 링크를 작동시키고 파일 이름을 유용하게 만드는 측면에서 마이그레이션을 준비할 것입니다. 수작업이기 때문에 나중에 사용하지 않을 때는 하지 않는 것이 좋습니다.

정말 어떤 피드백도 드릴 수가 없습니다. 나는 프로젝트에 대한 기본적인 관리 작업만 할 수 있습니다.

좋아, 그럼 나는 @dromer 에게 그의 의견을

안녕하세요, 저는 wiki를 github으로 마이그레이션하는 것에 대한 토론을 본 적이 없습니다.

우리가 가진 모든 정보를 단일 리소스에 집중하는 것이 합리적이라고 생각합니다. 그러나 우리가 마이그레이션하는 정보도 관련성이 있어야 하고 기존 정보를 제거해야 합니다.

github wiki 및 페이지에 대한 나의 경험은 거의 존재하지 않으므로 거기에 실제로 언급할 수 없습니다.

[편집: 아 페이지는 지킬 사이트 같은 것입니다. 자동 포맷터를 선호합니까?]

아 페이지는 지킬 사이트 같은 것입니다.

요, 그 정도입니다. 위키 btw도. 차이점은 페이지는 사이트에 사용되는 반면 위키는 정렬/구성되지 않은 정보의 대략적인 집합에 대한 것입니다. 이것은 (마이그레이션의 첫 번째 테스트 동안) 파일 이름이 기본 서버에서 자동으로 추측되기 때문에 몇 가지 문제를 일으켰습니다(예: 대소문자 구분으로 인해 문제가 발생함).

당신은 문장으로 무엇을 의미합니까

자동 포맷터를 선호합니까?

스타일링/레이아웃을 말씀하시는 건가요?

죄송합니다. 사이트 생성기를 의미했습니다. github 페이지가 jekyll 이외의 다른 페이지를 사용할 수 있다고 생각합니까?

jekyll이 Wiki를 구성하는 가장 쉽고 좋은 방법인지는 확실하지 않습니다. github Wiki보다 정확히 어떤 이점이 있을까요?

나는 우리가 아직 주요 partkeepr 웹사이트를 호스팅해야 한다고 생각하지 않습니다. Wiki와 같은 최신 정보 리소스에 집중합시다.

github wiki에도 일부 조각난 페이지가 있다고 생각합니다. 이 모든 것은 프로젝트의 현재 상태에 대한 적절하고 정확한 정보로만 수렴되어야 합니다.

죄송합니다. 사이트 생성기를 의미했습니다. github 페이지가 jekyll 이외의 다른 페이지를 사용할 수 있다고 생각합니까?

괜찮아요. 아직 완전히 해결하지 못했을 수도 있습니다.

jekyll이 Wiki를 구성하는 가장 쉽고 좋은 방법인지는 확실하지 않습니다. github Wiki보다 정확히 어떤 이점이 있을까요?

글쎄, 내가 볼 때 그 차이는 솔직히 말해서 미미하다. 둘 다 마크다운(또는 pandoc이 읽을 수 있는 형식)을 취하고 좋은 방식으로 형식을 지정합니다.
위키가 네임스페이스를 허용하지 않고 링크와 해당 파일 이름 간의 매핑이 일종의 휴리스틱이라는 문제를 발견했습니다.

• 위키에는 제목( 1 , 2 )만 다른 두 페이지가 있습니다. 휴리스틱이 올바른 것을 선택하도록 하려면 이 중 하나를 수동으로 제거해야 했습니다.
• 일종의 네임스페이스로 사용되는 하위 폴더는 git을 사용하여 수동으로 체크아웃할 때만 생성할 수 있습니다. 링크는 이 네임스페이스를 준수하지 않으므로 각 파일 이름을 한 번만 가질 수 있으므로 폴더 구조가 실용적이지 않습니다. 두 파일의 이름이 같은 경우 github에서 이름을 지정할 페이지를 어떻게 선택하는지 모르겠습니다.

github Pages 솔루션의 또 다른 장점은 아직 게시하지 않고도 jekyll을 로컬에서 실행하여 모양과 모든 링크를 확인할 수 있다는 것입니다. 또한 더 많은 스타일링을 할 수 있다고 생각합니다(하지만 확인해야 할 것입니다).

나는 우리가 아직 주요 partkeepr 웹사이트를 호스팅해야 한다고 생각하지 않습니다. Wiki와 같은 최신 정보 리소스에 집중합시다.

아니요, 현재 좋은 위치에 있는 것 같아요.
메인 홈페이지에 github 를

이 문제의 요점은 서버가 다운될 경우를 대비하여 현재 위키를 보존하는 것입니다.

github wiki에도 일부 조각난 페이지가 있다고 생각합니다. 이 모든 것은 프로젝트의 현재 상태에 대한 적절하고 정확한 정보로만 수렴되어야 합니다.

예 및 아니오. 최신 버전의 소프트웨어와 관련되어야 합니다. 그러나 나는 문서가 프로젝트에서 비교적 낮다고 생각합니다. 인력이 부족하다는 것을 알고 있지만 문서가 없으면 사용자는 소프트웨어 기능이 어떻게 작동하는지 확인하는 데 더 많은 문제를 겪습니다.
그래서 나는 문서를 가장 최신 버전으로 업데이트할 것을 약속하지만, 예를 들어 이전 상태의 마이그레이션 가이드를 유지하고, 상당히 오래된 버전에 대한 문서를 유지합니다(더 나은 가독성을 위해 일부 페이지를 분할할 수 있음).

설정 방법에 대한 힌트와 트릭을 추가하여 커뮤니티에서 관심을 끌기를 바랍니다. 지난 며칠 동안 고대 문제를 처리하면서 커뮤니티 회원들로부터 꽤 좋은 아이디어를 보았습니다. 위키 같은 페이지에서 언급할 가치가 있을 것입니다.

어느 쪽이든 행복합니다. 하지만 유지 관리사가 있으면 좋은 생각이 될 것입니다. 내 경험은 이러한 것들이 빨리 늙는다는 것입니다.

그것은 사실이다. 문서를 최신 상태로 유지하기 위해 전담하는 한 사람을 의미합니까?

이런 식으로 프로젝트를 도와도 괜찮습니다. 나를 잘못 이해하지 마십시오. 나는 이 입장을 강요하지 않습니다. 합의하에 결정해야 합니다.
현재로서는 문서화할 새로운 항목이 많지 않습니다. 주로 기존 것을 업데이트합니다. 프로젝트가 다시 주목을 받고 새 코드가 작성/변경되면 이는 변경될 수 있습니다. 그러면 관리자가 모든 기술적인 세부 사항을 이해할 수 없다는 점에서 문서의 유지 관리자는 개발자의 지원에 의존하게 됩니다.

오늘은 힘이 좀 생겨서 몇 가지 생각을 해보겠습니다.

• 현재 위키에서는 등록을 비활성화하고 수동으로 사용자를 생성해야 했기 때문에 사람들이 문서를 제공하기가 어렵습니다.
• GitHub 통합 위키는 특히 메인 페이지에서 제대로 링크되지 않은 페이지가 많은 경우 탐색을 어렵게 만듭니다.
• 문서 기여가 쉬워야 합니다. 사용자가 단순히 "페이지 편집" 버튼을 클릭하여 기존 콘텐츠를 편집하고 버튼을 클릭하여 새 콘텐츠를 만들 수 있는 곳이 좋습니다. 내가 좋아하는 예는 다음에서 찾을 수 있습니다. http://marlinfw.org/docs/configuration/configuration.html - 변경 사항은 끌어오기 요청을 생성하므로 문서 관리자가 검토하고 적절하게 연결할 수 있습니다.
• 그러나 이전 예에는 "새 페이지" 버튼이 없으므로 어떻게 할 수 있는지 확실하지 않습니다.

• 현재 위키에서는 등록을 비활성화하고 수동으로 사용자를 생성해야 했기 때문에 사람들이 문서를 제공하기가 어렵습니다.

그것은 어떻게 든 위키와 모순되지만 나는 필요를 이해합니다.

• GitHub 통합 위키는 특히 메인 페이지에서 제대로 링크되지 않은 페이지가 많은 경우 탐색을 어렵게 만듭니다.

그것은 완전히 사실입니다. 나는 위키가 어떻게 만들어지는지 그다지 미학적이지 않다고 생각합니다. 탐색을 단순화하기 위해 위키 전체에 미세한 링크가 존재하는지 확인해야 합니다.

• 문서 기여가 쉬워야 합니다. 사용자가 단순히 "페이지 편집" 버튼을 클릭하여 기존 콘텐츠를 편집하고 버튼을 클릭하여 새 콘텐츠를 만들 수 있는 곳이 좋습니다. 내가 좋아하는 예는 다음에서 찾을 수 있습니다. http://marlinfw.org/docs/configuration/configuration.html - 변경 사항은 끌어오기 요청을 생성하므로 문서 관리자가 검토하고 적절하게 연결할 수 있습니다.
• 그러나 이전 예에는 "새 페이지" 버튼이 없으므로 어떻게 할 수 있는지 확실하지 않습니다.

그들은 github 페이지 기능을 사용하지만 기본 기능보다 더 정교한 설정을 사용합니다. 아직 모든 것을 살펴보진 못했지만 이것저것 살펴볼 수 있어요...

사용자는 https://readthedocs.web.cern.ch/display/PARTK 에서 공유되는 로컬 WIKI에서 적극적으로 정보를 수집합니다.
그는 이 정보를 다른 위치로 이식하겠다고 제안했지만 프로젝트 팀의 지침이 요청되었습니다. 이에 대한 스레드는 PartKeepr Google Groups https://groups.google.com/g/partkeepr-users/c/ehqapXqyY0o/m/1VWkA00dDAAJ 에서 찾을 수 있습니다.