it-swarm-ko.tech

작업, 프로세스 및 환경을 어떻게 문서화하고 있습니까?

위키 형식을 사용하고 있습니까? 그렇다면 어떤 제품입니까? (미디어 위키, 합류점, 쉐어 포인트 등)

지식 기반을 만들었습니까? (문제/솔루션 중심의 짧은 문서)

효과적인 문서를 작성하면 어떤 어려움을 겪고 있습니까? 휴일에 외출 할 때 전화를받지 않습니까?

저에게는 문서를 완성하는 것과 관련하여 일정량의 조직적 "관성"이있는 경우가 종종 있습니다. 작업을 수행 할 수있는 다른 종류의 사람인 것 같습니다. 어떻게 작업을 수행하고 다른 사람이 수행 할 수 있도록 설명합니다. 모두가 그렇게 편안하지는 않습니다.

최신 정보

지금까지 답변은 다음과 같습니다.

  • 합류
  • 플렉스 위키
  • 포그 버그
  • 미디어 위키 (fckeditor와 같은 플러그인 포함)
  • 공유 지점
  • 트 위키
  • 워드/엑셀/Visio Docs
  • 문서화 된 스크립트

편집하다: 모니터링 시스템으로 네트워크를 암시 적으로 문서화하지 않습니까? Nagios는 항상 parents 지시문을 사용하여 네트워크 구조를 반영하도록 권장했으며 notes_url 지시문은 위키 또는 기타 브라우저 기반 문서에 링크 할 수 있도록 설계되었습니다. . 여기에서 "문서"는 모니터링 시스템의 "살아있는 문서"와 위키의 더 자세한 오프라인 문서로 나뉩니다. 내가 Nagios를 응시하는 데 많은 시간을 소비하기 때문에 가능한 한 유익한 정보를 얻기 위해 노력하는 것이 합리적입니다.

48
Cawflands

툴링에 대한 주석.

우리는 온라인 위키를 시험해 보았지만 개인적인 취향이지만 문서 구조와 문서 서버에 가장 중요하게 연결되어야하는 많은 제한 사항을 발견했습니다.

오프라인이거나 현장에있는 경우 연결되는 것은 심각한 문제입니다 (확실히 SSL 연결 등으로 현장을 완화 할 수 있음).

현재 문서화 프로세스는 다음과 같습니다.

  • 정적 HTML 생성기
  • 마크 다운 구문
  • 분산 버전 관리 시스템

우리는 문서를위한 '형식적인'레이아웃을 가지고 있으며 메뉴의 구조 (및 비주얼 스타일링을위한 관련 CSS)를 제공합니다.

정적 HTML 생성기

cubictemp 및 기타 여러 도구를 기반으로하는 사내 정적 HTML 생성기를 사용합니다 : pygments , docutils .

우리/시스템 관리자/프로그래머 대부분은 미적으로 아름다운 것이 무엇인지 알고 있지만 그러한 구성에 대한 조정이 완전히 부족하기 때문에 생성 된 페이지는보기 흉하지 않습니다.

그러나 html 형식화에 대해 걱정하거나 다운로드를 위해 '서버'에서 찾을 위치에 대해 걱정할 필요없이 구성 파일, 샘플 스크립트, pdf 등을 포함시킬 수 있습니다.

HTML이 아닌 경우 폴더에 드롭하고 URL 링크를 추가하십시오.

HTML은 레이아웃을위한 '잠재적'구조를 제공하고, 지식/컨텐츠 항목 (메뉴, 컨텐츠 테이블 등을 만들 수있는 것과 같은 기본 구조 메커니즘) 사이의 '링크'를 비판적으로 제공합니다. HTML을 사용하면 각 사용자는 lighttpd이든 작든 아파치 나 IIS로 가득 찬 작은 웹 서버를 컴퓨터에서 실행하십시오.

우리의 모든 기계에는 기본 html 서빙에 대한 불만이 있으며 충분히 잘 작동합니다.

MARKDOWN 구문.

우리는 MARKDOWN, Textish 및 reStructuredTEXT 의 나쁜 버전을 사용하여 '크리에이티브'주스가 HTML에 대해 걱정할 필요없이 문서를 작성할 수 있도록합니다.

또한 모든 사람들이 자신이 좋아하는 편집기 (Windows 및 * Nix에서는 Scintilla를 사용함)를 사용하고 다른 사람들은 vi/vim을 사용합니다.

분산 버전 관리 시스템.

우리는 Git 를 사용하여 사용자들 사이에서 문서를 '배포'합니다. 아, 우리는 그것도 버전 관리 용량을 사용합니다.

우리에게 가장 큰 장점은 서버에 연결하지 않고도 '완료된'저작물을 게시하지 않고도 문서를 업데이트 할 수 있다는 것입니다. 우리는 모두 문서의 동일한 부분이나 다른 부분에서 작업하거나 정보를 사용할 수 있습니다.

개인적으로, 나는 Wiki는 물론 블로그를 업데이트하기 위해 서버에 묶인 것을 싫어합니다. 힘내는 우리를 위해 잘 작동합니다.

워크 플로우에 대한 주석

Wiki는 지식 전파/목록 화를위한 "패션"으로 보이지만 다른 곳에서는 모든 프로세스를 유지하기가 어려워지고 팀의 요구를 가장 잘 지원하고 지속 가능한 도구 조합을 찾는 데 시간이 걸립니다.

더 나은 솔루션은 발견되고 의무화되지 않습니다.

8
samt

우리는 내가 일하는 곳에서 DokuWiki 를 사용하기 시작했습니다.

Dokuwiki 웹 사이트에서 :

DokuWiki는 표준을 준수하고 사용하기 쉬운 위키로, 주로 모든 종류의 문서 작성을 목표로합니다. 개발자 팀, 작업 그룹 및 소규모 회사를 대상으로합니다. 단순하지만 강력한 구문을 사용하여 Wiki 외부에서 데이터 파일을 읽을 수있게하고 구조화 된 텍스트를 쉽게 만들 수 있습니다. 모든 데이터는 일반 텍스트 파일로 저장되며 데이터베이스가 필요하지 않습니다.

Dokuwiki는 데이터베이스가 필요하지 않기 때문에 구현하기가 가장 쉽고 설치가 쉽다는 것을 알았습니다. 또한 기존의 Active Directory 계정 로그온 을 사용하는 대신 모든 사용자를위한 계정을 만들어야하는 추가 기능 모듈도있었습니다. 또한 일반적인 버전 관리 기능을 통해 누가 어디에 어디에 게시했는지 알 수 있으며 필요한 경우 이전 버전으로 쉽게 롤백 할 수 있습니다. 또한 사용자 정의 가능한 홈페이지가 포함되어있어 환경에 가장 적합한 유형의 컨텐츠를 쉽게 변경할 수 있습니다.

7
mrTomahawk

올바른 플러그인을 사용하면 Trac 이 조합 티켓과 위키 시스템이 될 수 있습니다. 이렇게하면 티켓이 위키 기사에 쉽게 링크되고 그 반대도 마찬가지입니다.

내가 좋아하는 몇 가지 플러그인 :

  • 개인 티켓 플러그인 . Trac은 모든 티켓과 응답이 공개되는 버그베이스로 구축되었습니다. IT 티켓 시스템에는 적합하지 않지만이 플러그인은이를 해결합니다.
  • 트랙 WYSIWYG 플러그인 . 대부분의 사람들은 당신을 행복하게하기 위해 위키 구문을 배우지 않을 것입니다. 이를 통해 티켓과 위키 페이지 모두에 대해 '당신이 보는 것'을 얻을 수 있습니다.

Trac에 대한 more 커스터마이징이 꽤 있습니다. Trac 시스템을 원하는대로 설정하고 사용자 정의하는 것은 어렵지 않습니다!

6
quux

Doku Wiki 또는 차트에 맞는 다른 것들에 대한 Sharepoint.

당신은 위키에 게시하는 데 꽤 빨리 익숙해지며 구문은 실제로 그렇게 복잡하지 않습니다. 정보를 구성하는 것은 매우 쉽고 나중에 다른 사람이 쉽게 찾을 수 있도록합니다.

Visio를 사용하여보다 명확한 설명을 위해 그래프를 만듭니다 (JPEG로 내보내기).

6

우리는 위키를 사용하고 있습니다. 실제로, 우리는 미디어 위키를 사용하고 있습니다. MediaWiki 위에 Semantic Mediawiki extension 가 설치되어 있는데, 이것은 실제로 MediaWiki를 카테고리, 제목, 내용 등으로 쿼리 할 수있는 느슨한 유형의 데이터베이스로 바꿉니다.

예를 들어 클러스터 F를 통해 라우팅되는 모든 네트워크 cname을보고 싶다고 가정 해 보겠습니다. Special : Ask 페이지를 사용하여 [[Category : cname]] [[destination :: cluster_f]]을 쿼리하기 만하면됩니다. 대상을 cluster_f로하여 cname으로 분류 된 모든 페이지를 반환합니다.

우리는 수백 명의 매우 이질적인 고객을 지원하므로 문서를 중앙 위치에 보관하고 (특별한 사례를 문서화하고 전체적으로 묶을 수 있도록 교차 연결) 큰 도움이됩니다. 분명히, 우리의 문서는 유지되어야하지만, 큰 데이터 세트를 최신 상태로 유지하기위한 미디어 위키 툴킷은 이미 상당히 성숙되어 있기 때문에 유지 보수에 대한 '정원사'접근 방식을 더 많이 사용할 수 있습니다.

6
Karl Katzke

이전 작업에서 Twiki를 사용했습니다. 꽤 잘 작동했습니다.

그 옆에서 나는 대부분의 작업을 자동화하고 스크립트를 문서화하는 경향이 있습니다 (항상 열정이 많지는 않지만 여전히 ...). 스크립트를 문서화하는 과정은 스크립트를 디자인하는 과정에서 쉽게 수행되므로 실제 오버 헤드는 없습니다 ...

스크립트와 버전 제어를 함께 사용하면 트릭을 상당히 잘 수행 할 수 있습니다.

5
Vincent De Baere

JIRA, Confluence 및 Word 문서가 혼합되어 있습니다.

5
Andrew

교육 기관 지식

우리는 문서부터 시작했습니다. 그런 다음 그중 일부를 Sharepoint 라이브러리에 저장했습니다. 그런 다음 최근에 Sharepoint wiki로 옮겼습니다. Sharepoint의 Wiki는 테이블과 같은 것들에 대한 그래픽 지원 및 서식 지원에서 원하는 것을 남겨 두지 만 Wiki의 저 마찰 방식으로 빠르게 업데이트합니다. 텍스트에 적합하며 내장 편집기를 사용하면 기본적인 HTML 형식과 순서/순서가없는 목록을 사용할 수 있습니다. Sharepoint에 대한 다른 저렴한 대안이 있습니다.

또한 지원 데스크 소프트웨어 인 Numara 's Track-It에 지원 티켓에 대한 비공식 지식 기반이 있습니다. 완벽하지는 않지만 작동합니다.

직원이 제도화 된 지식을 사용하도록하기

지식을 제도화하는 것이 전쟁의 한 부분 일 뿐이라는 귀하의 평가에 동의합니다. 당신의 조직과 사람들이 "먼저 연구하고, 두 번째로 물어 보는"방법에 익숙하지 않다면, 옛날 방식이 우세하다는 것을 알게 될 것입니다. 직접 검색하는 것보다 내 옆에있는 사람.

이를 처리하기 위해서는 몇 가지 변경 관리가 필요합니다. 소규모 팀 이상에 영향을 미치는 가장 성공적인 변화 이니셔티브와 마찬가지로 관리 승인 및 지원을받는 데 도움이됩니다. 당신은 정말로 두 가지 방향으로 새로운 행동을 만들어 내야합니다. 누군가는 지식을 포착해야하고 사람들은 그것을 사용해야합니다. 더 어려운 것은 사람들이 해당 데이터를 최신 상태로 유지해야한다는 것입니다.

단지 몇 가지 아이디어 : 아마도 해결 된 티켓과 이슈가 폐쇄 된 것으로 간주되기 전에 지식 기반이나 위키에 문서화되어야한다는 공식 정책의 형태로 격려가 필요할 것입니다. 또한 일반적으로 질문을받는 지식 리더는 항상 요청에 대한 답변 만 제공해서는 안됩니다. 그들은 사람들이 위키를 가리키고 먼저 그곳을 확인하는 데 익숙해 져야합니다. 또 다른 문제는 사용자가자가 진단을 위해 데이터를 사용할 수 있도록하여 기술 담당자가 저글링해야하는 또 다른 항목이되기 전에 문제를 해결할 수 있도록하는 것입니다.

좋은 점은 헬프 데스크 시스템에 StackOverflow 및 ServerFault와 유사한 시스템이 있다는 것입니다. 질문을 입력하면 검색 엔진이 유사한 항목을 찾아서 제공하므로 사용자는 질문을 제출하기 전에도 해당 항목을 볼 수 있습니다.

5
Bernard Dy

마지막 두 곳에서 Wiki 문서로 쉽게 만들 수없는 특정 문서 (예 : DRP 및 일회성 업그레이드 계획)가 포함 된 문서 라이브러리와 함께 Sharepoint의 Wiki를 사용했습니다. 그 문서들은 위키 내에서 링크를 가지고있었습니다. Wiki는 많은 사람들이 편집 할 수 있고, 버전 관리 기능이 내장되어 있고, 쉽게 검색하고 액세스 할 수있는 등이 영역에서 많은 이점을 가지고 있습니다. 메모 나 아이디어를 빠르게 기록하려면 OneNote 또는 화이트 보드를 사용합니다.

포럼 형식 (Lotus Notes 및 MS Sharepoint 모두)으로 일부 지식 기반을 만들었지 만 특정 문제가 이미 해결되었는지 확인하기 위해 사람들을 통해 정보를 찾는 경우는 거의 없습니다. 이러한 솔루션은 매우 강력하고 효과적인 검색 엔진을 갖춘 첫날부터 이루어져야합니다.

휴일에있을 때 사용할 수있는 문서를 만들려면 부모 중 한 사람에게 지시하는 것처럼 작성하십시오. 이것은 100 % 바보가 아니지만 때때로 도움이됩니다. 누가 읽고 있는지에 따라 다릅니다.

4
Moshe

Sharepoint는 멋지다.

검색 기능은 거의 모든 유형의 문서를 색인화 할 수있어 문서 검색이 매우 쉽습니다.

예를 들어 구축하는 각 서버에 대한 표준 정보 시트가있는 경우 더 쉽게 만들 수있는 템플릿을 사용할 수 있습니다.

또한 문서의 버전을 지정할 수 있으므로 설명서 변경 내역을 기록 할 수 있습니다.

또한 문서 라이브러리에 포함 된 파일은 웹, Outlook 또는 unc 공유를 통해 즉시 액세스 할 수 있습니다.

4
Dominic D

우리는 몇 년 동안 MediaWiki (fckeditor와 함께)를 사용해 왔지만, 사진 (예 : 스크린 샷) 처리가 더 쉬웠다면 좋을 것이라고 말해야합니다. 그리고 검색 기능이 필수적이지만 MediaWiki의 검색은 종종 페이지를 빠뜨립니다. 아마도 그것은 더 나은 검색을 배우는 문제 일 것입니다 (다른 사람들이 귀하의 작업을 수행 할 수있는 간단한 방법을 갖는 목적을 상실합니다)

지금은 위키에 반드시 필요한 것은 아니지만 모든 것을 MS Sharepoint로 옮기는 것에 대해 이야기하고 있습니다. Sharepoint는 위키의 장점을 무효화하는 방식으로 전체 문서 검색을 수행 할 수 있다고 생각합니다.

(현재 문서를 모두 포팅하는 과정을 기대하지는 않습니다.)

3
Brent

우리는 위키를 사용하고 있습니다. 구문에 익숙해지기는했지만, 우리가 사용하는 구문 (twiki)은 데이터를 텍스트 파일로 완전히 저장합니다. 이를 통해 재난 발생시 쉽게 읽을 수 있으며 어디에서나 복원 할 수 있고 grep을 통해 명령 줄에서 검색하고 원하는 텍스트 편집기에서 읽을 수 있습니다.

모든 서버에는 변경 관리 정보, 시작/종료 및 구성 정보와 dns, 방화벽 및 자산 정보에 대한 표준 하위 페이지 모음이있는 페이지가 있습니다.

3
Laura Thomas

내가 일하는 NGO에서는 중요한 절차를 위해 폴더에 배치 된 텍스트 파일을 사용합니다. 개인적으로 시스템 관리자/웹 개발자 하이브리드로서 트리 디렉토리에 흩어져있는 텍스트 파일의 지식 기반을 사용하고 있습니다. 내 Memex 이며 거의 모든 것을 적어 둡니다 (개인, 작업 등) ). 이 체계는 텍스트 처리에 Jedit 실제 스위스 군용 칼을 사용하여 관리하는 것이 매우 쉽습니다. 개요 플러그인, 코드 접기 및 하이퍼 검색 기능이 필수적이라는 것을 알았습니다. 이 모든 것이 rsync에 의해 ssh 액세스 가능 원격 서버에 안전하게 백업됩니다.

alt text

Makelink Firefox Extension 과 결합하면 완벽한 북마크 관리자가 있습니다.

2
cgomezsilva

우리는 세 버전의 서버에 분산 된 Word 문서와 몇 개의 폴더를 알고 있는지 혼합하기 위해 일부 버전의 Sharepoint 서비스로 이동할 준비를하고 있습니다. 현재이 문서에 설명 된 문서에 대한 하이퍼 링크가 포함 된 방대한 Excel 스프레드 시트가 있습니다.

가장 좋은 방법은 아니지만 회사가 시작했을 때 내부 문서를 처리하는 방법을 계획하지 않았고 각 그룹에 맡겨 자신의 문서를 정렬하고 저장하는 방법을 결정했습니다. 이제 우리는 Sharepoint 오퍼링 중 하나 인 통합 시스템으로 통합하려고합니다.

2
user41811

이 질문은 this one 의 복제본과 매우 잘 맞으며 대답을 거기로 옮겼습니다.

1
jtimberman

또 다른 질문 에 대답하기 전에이 질문을 보지 못했지만 여기에갑니다.

우리는 많은 도구와 방법을 사용합니다.

  • 기능 사양 인프라 구성 요소 및 소프트웨어의 경우.
  • 두 개의 Confluence Wikis . 하나는 내부 회사 문서 (정책, 절차, 내부 인프라 및 IT 등)와 오픈 소스 소프트웨어 제품을위한 것입니다.
  • RSpecCucumber 테스트. 우리의 소프트웨어는 대부분 루비로 작성되었으며 BDD / TDD 사양 테스트는 실제 코드를 주도하고 문서화합니다.
  • 인라인 코드 문서. 코드 주석에는 RDoc 마크 업을 사용합니다.
  • 선언적 구성 관리 ( Chef ). 우리의 모든 서버는 Chef로 관리되며, Chef는 레시피 및 요리 책에 대한 열렬한 리소스를 통해 "자체 문서화"합니다.

Confluence는 매우 유연하고 강력하며 완벽한 기능을 갖추고 있으며, 원하는 티켓 관리 소프트웨어 인 Jira 에 연결되어 있기 때문에 Confluence를 좋아합니다.

내가 근무했던 이전 회사에서는 다양한 도구와 방법을 사용했으며 많은 사람들이 모든 것을 위해 하나의 포괄 리소스 (위키와 같은)를 유지하려고 노력했습니다. 문제는 그 주제를 다루는 데 적합하지 않은 단일 도구를 사용하여 다양한 주제를 문서화하는 것이므로 정보를 마이그레이션하기가 어렵 기 때문에 많은 것들이 전혀 문서화되지 않습니다. 유닉스/리눅스 괴짜로서 각 작업에는 특정 도구가 필요하며 그 도구는 그 작업에 매우 적합해야한다고 생각합니다.

1
jtimberman

컨텐츠 및 SharePoint에 ScrewTurn을 사용하여 문서/이미지를 저장합니다.

1
Jeff

흥미로운 점이 있습니다 here -나는 금고의 암호에 관한 것을 좋아합니다.

1
Preet Sangha

내가 사용한 문서 시스템으로 대답하지는 않지만 seen 사용하고 아주 좋은 것으로 - http : //stackexchange.com/

stackexchange는 serverfault에서 실행되는 Q & A 플랫폼입니다. 기술적으로 정확히 동일하지는 않지만 여기서는 동일한 것으로 가정 할 수 있습니다.

Fogbugz 사용 .

Fogbugz 직원의 흥미로운 blog post 이 인용구를 찾았습니다.

제품 사양 이외의 모든 목적을 위해 회사 위키와 토론 양식이 치명적인 타격을 받았다고 생각합니다.

...

지원 플랫폼으로 FogBugz.StackExchange.com을 사용하기 시작한 이후로 동일한 질문에 두 번 답변 한 적이 없습니다. 비공개 Q & A에 사용하는 내부 SE 서버도 있으며 동일한 원칙이 적용됩니다.

고객 대면 기술 자료 및 내부 기술 자료에 대해 스택 교환을 사용합니다.

이러한 지식 교환 Q & A 플랫폼이 회사 위키를 대체 할 것인지 알고 싶습니다.

1
Steven

우리는 flexwiki 를 사용하는데, 이것은 닷넷이며 오픈 소스입니다.

1
James Moore

음 ... 포그 버그는 어때요? :)

1
Chopper3

회사에 대한 대부분의 문서를 작성했으며 여기에서 작업을 시작할 때 설정 한 형식은 편집 가능한 원본의 MS Word이며 PDF 읽기 전용 일반 릴리스의 경우)로 내보내졌습니다. 한 사람 만 문서를 업데이트하는 프로젝트에 적합하며, 그 사람은 보통 나이므로 관리자는 변경할 필요가 없습니다.

코드 검토를 위해 "Peer Review"확장을 사용하면서 Trac 로 버그 및 향후 작업을 문서화하기 시작했습니다. 협업하기 쉽고 탐색하기 쉽기 때문에 팀의 큰 호응을 얻었습니다. 다른 몇몇 팀원들은 사양, 테스트 절차 및 매뉴얼과 더 많은 협업을 시작하기를 원했기 때문에 설명서와 같은 공개 문서를 위해 PDF 사양 및 테스트 절차와 같은 내부 문서를위한 Trac WIKI 페이지.

내 생각에 문서 형식을 선택할 때 가장 큰 문제는 다음과 같습니다.

  1. 쉽게 만들 수 있습니까?
  2. 유지 관리가 용이합니까?
  3. 다른 사람이 작성한 경우 유지 관리하기가 쉽습니까?
  4. 번거 로움없이 다른 형식으로 내보내거나 변환 할 수 있습니까?

1-3은 내 인생을 더 편하게 만들고, 제 정신을 잃지 않고 문서를 빠르게 제작하는 데 중요합니다. 형식이 계속 바뀌기 때문에 네 번째 형식은 고객 쪽에서 가장 중요하다고 생각합니다. Microsoft Word 2003 형식은 영원히 사용되지 않으며 현재 PDF를 구현하지도 않습니다. OS 나 문서 선택의 종류에 상관없이 모든 고객이 문서를 읽을 수 있는지 확인해야합니다.

1
andrewd18

Grep으로 빠른 검색을 위해 텍스트 파일 조합을 사용합니다. 보다 체계적인 심층 문서 모음 (Visio 다이어그램 등)을위한 SharePoint.

1
TCampbell

Google Apps (Enterprise) 고객으로서 Google 사이트 도구 인 위키 "맛"을 사용합니다. 사용하기 쉬우 며 관리자와 개발자들로부터 큰 호응을 얻었습니다.

1
Chris_K

우리는 SemanticMediaWiki를 포함한 다양한 플러그인과 함께 MediaWiki를 사용합니다. SMW는 MediaWiki 설치를 자유롭고 자유로운 형태의 관계형 데이터베이스로 전환하여 자유롭게 문의 할 수 있기 때문에 좋습니다. 웹 사이트가 어느 서버에 있는지 알아야합니까? 페이지를 방문하십시오. 어떤 웹 사이트가 서버에서 호스팅되는지 알아야합니까? 검색어를 실행하면 각 웹 사이트 페이지의 적절한 태그를 기준으로 페이지 이름이 선택됩니다.

1
Karl Katzke

직장에서 ScrewTurn Wiki를 Windows 개발 서버 중 하나에 놓고 SQL Server에 연결했습니다. 실제로 잘 작동하고 빠르게 실행되며 주로 문서화를 방해합니다. 배포 된 지 2 주 만에 이미 약 60 페이지의 정보를 추가했으며 팀 전용 (~ 10 명)입니다.

지금까지 우리는 현재 및 과거 프로젝트에 대한 정보를 유지하고 처음부터 새로 작성하는 방법, URL 및 팀에 새로운 개발자를위한 기타 중요한 정보와 같은 애플리케이션에 대한 정보를 추가하기 시작했습니다.

위키에서 내가 가장 좋아하는 페이지 중 하나는 도구 및 라이브러리 페이지입니다. 여기에서 자주 사용하는 자주 사용하는 생산성 도구 및 라이브러리에 대한 정보를 추가하기 시작했습니다. 그 예로 Windows에서 텍스트 검색을위한 grepWin이 있습니다.

사용 가능한 전체 위키 범위를 확인하고 원하는 사용법, 기능 및 배치 환경에 적합한 것을 찾으십시오. 사용하기 쉽기 때문에 ScrewTurn을 선택했으며 로컬 WinServer에는 많은 여유 공간이 있지만 YMMV가 있습니다.

0
MattGWagner

Redmine을 사용해보십시오. 나는 대학 프로젝트뿐만 아니라 산업 프로젝트에도 사용했습니다.

위키, 문서, 메모, svn (git에서 작업하고 있다고 생각합니다), 기능 요청, 정교한 버그 추적 및 개발을 모니터링하기 위해 모든 것이 간트 차트에 자동으로 추가됩니다.

다양한 레벨의 사용자 (개발자, 관찰자, 사용자 등)를 추가하고 모든 사람간에 많은 정보를 공유 할 수있는 매우 멋진 플랫폼입니다.

http://www.redmine.org

0
DarwinSurvivor

경우에 따라 Confluence를 Wiki 및 문서 공유 지점으로 사용하고 있습니다. 온라인 위키 형식은이 정보를 실제로 광범위하게 공유해야 할 때 선호되며 문서를 매우 자주 편집하고 업데이트 할 때 훨씬 더 중요합니다. 그래서 나는 지식 기반 기사를 위키에 넣는 것이 낫다고 생각합니다.

0
Leonid Shirmanov

현재 네트워크에 분산 된 다양한 문서에서 두 위치로 정보를 이동하고 있습니다.

  1. 인트라넷에서 사용 가능한 위키
  2. 해당 서버/root 디렉토리에있는 특정 서버와 관련된 정보의 사본.

네트워크 다이어그램의 경우 Network Notepad .

또한 무엇을 기록하는 동안 무언가가 어떻게 구성되어 있는지 기록해야합니다. 이렇게하면 좋은 아이디어처럼 보이는 아이디어가 실수로 바뀌는 것을 방지 할 수 있습니다.

0
David

MindTouch Deki (DekiWiki 또는 "MindTouch"라고도 함)는 여러 가지 이유로 여기에서 선택합니다.

  • 그것은 모양과 모양이 훌륭하지만 확장 기능, 스크립트 또는 템플릿으로 쉽게 확장 가능합니다.
  • wYSIWYG 편집기를 사용하므로 사용자는 "위키 텍스트를 배우고 싶지 않습니다"를 문서화하지 않기위한 변명으로 사용할 수 없습니다
  • 모든 데이터는 XML로 저장되므로 모든 페이지를 XML 웹 서비스로 운영 할 수 있습니다.
  • REST (표준 HTTP 동사)로 작동하는 사용하기 쉬운 API
  • 환상적인 스크립팅 언어, DekiScript , 매시업을 사소하게 만들기
  • 절대적으로 아름다운 PDF - Prince , CSS 작성자의 HTML/CSS 엔진을 사용한 출력

어떻게 사용합니까? 완전한 지식 기반으로서 각 부서별로 섹션으로 나뉘어 있으며, 정보가 필요할 수있는 모든 페이지가 그 아래에 있습니다!

네트워크 모니터링 시스템과 관련하여 Zenoss 설치의 라이브 데이터를 구성 노트 및 기타 향후 매시업과 같은 항목을 위해 MindTouch Wiki 페이지에 배치하기위한 Zenoss/MindTouch Deki 매시업 을 다운로드 할 수 있습니다.

오픈 소스 에디션은 "코어"로 판매되며 상용 에디션의 애드온 기능에는 SugarCRM 및 Salesforce와 같은 서비스 용 커넥터와 Microsoft SQL Server와 같은 데이터베이스가 포함됩니다. 또한 상용 고객은 Windows 커넥터 (Outlook/Word 등) 및 위키 조작을위한 데스크톱 응용 프로그램에 액세스 할 수 있습니다.

IIS에 설치하는 것은 MySQL을 설치 한 다음 MSI를 설치하는 것만 큼 간단합니다. MSI는 기술적으로 엔터프라이즈 판에만 해당되지만 오픈 용으로 사용하기위한 해결 방법 이 있습니다. 대안은 VM 어플라이언스 (특히 VMware 서버 인프라가 이미있는 경우)를 설치하는 것입니다.이 경우에는 구성이 전혀 필요하지 않습니다.

0
crb

우리는 MediaWiki가 느리게 시작했지만, IT 외부의 사람들이 댓글, 변경, 편집 등을 추가하는 것이 얼마나 쉬운 지 알게되면서 필수 불가결 한 것이되었습니다. 개발자는 내부 문서, 시설 부서에 사용하고 있습니다. 공지 사항 등을 게시하는 데 사용됩니다. IT 문서 도구가 아니라 그 이상입니다.

0
bren

이전 고용주에서 폴더에 함께 수집 된 Word, Excel 및 Visio 파일을 사용했습니다. 내 책상의 바인더에 모든 내용의 하드 카피가 보관되었습니다. 나는 유일한 IT 담당자 였으므로 다른 사람이 정보에 액세스 할 필요가 거의 없었습니다.

현재 고용주에서는 Exact Software의 Macola ES를 사용하지만 내장 문서 편집기를 사용하는 것보다 Word로 문서를 작성하여 첨부 파일로 Macola에 업로드하는 것을 선호합니다.

0
Scott

미디어 위키도 여기에 있습니다. 저는 제가 일하는 회계 회사의 유일한 IT 지원이므로이 시점에서 협업에 대해 걱정할 필요가 없습니다. 그럼에도 불구하고 Wiki는 정기적으로 수행하는 빠른 변경의 종류에 놀랍도록 잘 작동한다는 것을 알았습니다.

내가 가진 한 가지 문제는 민감한 모든 것 (즉, 암호)이 Wiki 외부의보다 안전한 저장소에 저장되지만 더 즉시 사용할 수 있다는 것이 좋습니다.

0
Nic