위키 형식을 사용하고 있습니까? 그렇다면 어떤 제품입니까? (미디어 위키, 합류점, 쉐어 포인트 등)
지식 기반을 만들었습니까? (문제 / 솔루션 중심의 짧은 문서.)
효과적인 문서를 만들면 어떤 어려움을 겪고 있습니까? 휴일에 외출 할 때 전화를받지 않습니까?
저에게는 문서를 완성하는 것과 관련된 조직적인 “관성”이 종종 있다는 것을 알게되었습니다. 작업을 수행 할 수있는 다른 종류의 사람인 것 같습니다. 그런 다음 작업을 수행 한 방법 에 대해 생각하고 다른 사람이 작업을 수행 할 수 있도록 설명합니다.
최신 정보
지금까지 답변은 다음과 같습니다.
- 합류
- 플렉스 위키
- 포그 버그
- 미디어 위키 (fckeditor와 같은 플러그인 포함)
- 공유 지점
- 트 위키
- 워드 / 엑셀 / Visio Docs
- 문서화 된 스크립트
편집 : 모니터링 시스템으로 네트워크를 암시 적으로 문서화하지 않습니까? Nagios는 항상 네트워크 구조를 반영하기 위해 부모 지시문을 사용하도록 권장했으며 notes_url 지시문은 위키 또는 기타 브라우저 기반 문서에 링크 할 수 있도록 설계되었습니다. 여기에서 “문서”는 모니터링 시스템의 “살아있는 문서”와 위키의 더 자세한 오프라인 문서로 나뉩니다. 내가 Nagios를 응시하는 데 많은 시간을 소비하기 때문에 가능한 한 유익한 정보를 얻기 위해 노력하는 것이 합리적입니다.
답변
툴링에 대한 주석.
우리는 온라인 위키를 시험해 보았지만 개인적인 취향이지만 문서 구조와 문서 서버에 가장 중요하게 연결되어야하는 많은 제한 사항을 발견했습니다.
오프라인이거나 현장에있는 경우 연결되는 것은 심각한 문제입니다 (확실히 SSL 연결 등으로 현장을 완화 할 수 있음).
현재 문서화 프로세스는 다음과 같습니다.
- 정적 HTML 생성기
- 마크 다운 구문
- 분산 버전 관리 시스템
우리는 문서를위한 ‘형식적인’레이아웃을 가지고 있으며 메뉴의 구조 (및 비주얼 스타일링을위한 관련 CSS)를 제공합니다.
정적 HTML 생성기
우리는 기반으로 집에 정적 HTML 생성기 사용 cubictemp : 및 기타 도구의 숫자 pygments , docutils을 .
우리 / 우리의 시스템 관리자 / 프로그래머 대부분은 미적으로 아름답지만 그러한 건축에 대한 조정이 전혀 없기 때문에 생성 된 페이지는 분명하지 않습니다.
그러나 HTML 파일 형식을 망칠 걱정이나 다운로드를 위해 ‘서버’에서 찾을 위치에 대해 걱정할 필요없이 구성 파일, 샘플 스크립트, pdf 등을 포함시킬 수 있습니다.
HTML이 아닌 경우 폴더에 드롭하고 URL 링크를 추가하십시오.
HTML은 레이아웃을위한 ‘잠재적’구조를 제공하고, 지식 / 컨텐츠 항목 (메뉴, 컨텐츠 테이블 등을 만들 수있는 것과 같은 기본 구조 메커니즘) 사이의 ‘링크’를 비판적으로 제공합니다. HTML을 사용하면 각 사용자는 이제 lighttpd이든 작든 아파치 나 IIS로 가득 찬 작은 웹 서버를 컴퓨터에서 실행하십시오.
우리의 모든 기계에는 기본 HTML 서빙에 대한 불만이 있으며 우리에게 충분히 잘 작동합니다.
MARKDOWN 구문.
우리는 MARKDOWN, Textish 및 reStructuredTEXT 의 나쁜 버전을 사용하여 ‘크리에이티브’주스가 HTML에 대해 걱정할 필요없이 문서를 작성할 수 있도록합니다.
또한 모든 사람들이 자신이 좋아하는 편집기 (Windows 및 * Nix에서는 Scintilla를 사용함)를 사용하고 다른 사람들은 vi / vim을 사용합니다.
분산 버전 관리 시스템.
우리는 Git 을 사용 하여 사용자간에 문서를 ‘배포’합니다. 아, 우리는 그것도 버전 관리 용량을 사용합니다.
우리에게 가장 큰 장점은 서버에 연결하지 않고도 ‘완료된’저작물을 게시하지 않고도 문서를 업데이트 할 수 있다는 것입니다. 우리는 모두 문서의 동일한 부분이나 다른 부분에서 작업하거나 정보를 사용할 수 있습니다.
개인적으로, 나는 Wiki는 물론 블로그를 업데이트하기 위해 서버에 묶인 것을 싫어합니다. 힘내는 우리를 위해 잘 작동합니다.
워크 플로우에 대한 주석
Wiki는 지식 보급 / 목록 화를위한 “패션”으로 보이지만 다른 곳에서는 모든 프로세스를 유지하기가 어려워지고 팀의 요구를 가장 잘 지원하고 지속 가능한 도구 조합을 찾는 데 시간이 걸립니다.
더 나은 솔루션은 발견되고 의무화되지 않습니다.
답변
우리는 내가 일하는 곳에서 DokuWiki 를 사용하기 시작했습니다 .
Dokuwiki 웹 사이트에서 :
DokuWiki는 표준을 준수하고 사용하기 쉬운 위키로 주로 모든 종류의 문서 작성을 목표로합니다. 개발자 팀, 작업 그룹 및 소규모 회사를 대상으로합니다. 간단하지만 강력한 구문을 사용하여 Wiki 외부에서 데이터 파일을 읽을 수있게하고 구조화 된 텍스트를 쉽게 만들 수 있습니다. 모든 데이터는 일반 텍스트 파일로 저장되며 데이터베이스가 필요하지 않습니다.
Dokuwiki는 데이터베이스가 필요하지 않기 때문에 구현하기가 가장 쉽고 설치가 쉽다는 것을 알았습니다. 또한 기존 Active Directory 계정 로그온을 사용 하는 대신 모든 사람에 대한 계정을 만들어야 하는 추가 기능 모듈도있었습니다 . 또한 일반적인 버전 관리 기능을 통해 누가 어디에 어디에 게시했는지 알 수 있으며 필요한 경우 이전 버전으로 쉽게 롤백 할 수 있습니다. 또한 사용자 정의 가능한 홈페이지가 포함되어있어 환경에 가장 적합한 유형의 컨텐츠를 쉽게 변경할 수 있습니다.
답변
차트에 맞는 다른 것들에 대한 Doku Wiki 또는 Sharepoint.
당신은 위키에 게시하는 데 꽤 빨리 익숙해지며 구문은 실제로 그렇게 복잡하지 않습니다. 정보를 구성하는 것이 매우 쉽고 나중에 다른 사람이 쉽게 찾을 수 있습니다.
visio를 사용하여보다 명확한 설명을 위해 그래프를 만듭니다 (JPEG로 내보내기).
답변
우리는 위키를 사용하고 있습니다. 실제로, 우리는 미디어 위키를 사용하고 있습니다. 미디어 위키 외에 , 시맨틱 미디어 위키 확장이 설치되어 있는데, 이는 실제로 미디어 위키를 카테고리, 제목, 내용 등으로 쿼리 할 수있는 느슨하게 형식화 된 데이터베이스로 변환합니다.
예를 들어 클러스터 F를 통해 라우팅되는 모든 네트워크 cname을보고 싶다고 가정 해 봅시다. Special : Ask 페이지를 사용하여 [[Category : cname]] [[destination :: cluster_f]]을 쿼리하기 만하면됩니다. 대상을 cluster_f로하여 cname으로 분류 된 모든 페이지를 반환합니다.
우리는 수백 명의 매우 이질적인 고객을 지원하므로 문서를 중앙 위치에 보관하고 (특별한 사례를 문서화하고 전체적으로 묶을 수 있도록 교차 연결) 큰 도움이됩니다. 분명히, 우리의 문서는 유지되어야하지만, 큰 데이터 세트를 최신 상태로 유지하기위한 미디어 위키 툴킷은 이미 상당히 성숙되어 있기 때문에 유지 보수에 대한 ‘정원사’접근 방식을 더 많이 사용할 수 있습니다.
답변
올바른 플러그인을 사용하면 Trac 은 티켓과 위키 시스템을 결합 할 수 있습니다. 이렇게하면 티켓이 위키 기사에 쉽게 링크되고 그 반대도 마찬가지입니다.
내가 좋아하는 몇 가지 플러그인 :
- 개인 티켓 플러그인 . Trac은 모든 티켓과 응답이 공개되는 버그베이스로 구축되었습니다. IT 티켓 시스템에는 적합하지 않지만이 플러그인은이를 해결합니다.
- Trac에 WYSIWYG 플러그인 . 대부분의 사람들은 당신을 행복하게하기 위해 위키 구문을 배우지 않을 것입니다. 이를 통해 티켓과 위키 페이지 모두에 대해 ‘당신이 보는 것이 무엇인지’편집기를 제공합니다.
Trac에 대한 몇 가지 추가 사용자 정의가 있습니다. Trac 시스템을 원하는대로 설정하고 사용자 정의하는 것은 어렵지 않습니다!
답변
이전 작업에서 Twiki를 사용했습니다. 꽤 잘 작동했습니다.
그 다음으로, 나는 대부분의 작업을 자동화하고 스크립트를 문서화하는 경향이 있습니다 (항상 열정이 많지는 않지만 여전히 …). 스크립트를 문서화하는 과정은 스크립트를 디자인하는 과정에서 쉽게 수행되므로 실제 오버 헤드는 없습니다 …
스크립트와 버전 제어를 함께 사용하면 트릭을 상당히 잘 수행 할 수 있습니다.
답변
JIRA, Confluence 및 Word Documents의 혼합.