- - use mailing lists
- - public review (anonymous CVS, commit emails)
- - bug tracking systems
- - licenses
- - download and test other peoples the programs
- - read other peoples code
- - give well-formed bug reports, and include a patch if possible
- - let everyone work on the things that interests them
- - do not accept every change. make sure you like it first
- - write down where you want the project to go
- - web pages
- - screen shots
- - short summary
- - who to contact for more info
- - source README
- - home page URL
- - download site URL
- - short description
- - where to send bug reports and patches
- - consider sourceforge
- - tools
- - compiler
- - libraries
- - debugging utilities (gdb, ddd, dmalloc, valgrind, electric fence,
- fncchk, etc)
- - avoid duplicate work (check freshmeat)
-
-
-- bruker
-
- - hold deg til de store distribusjenene
- - hvis du finner feil
- - fortell din lokale sysadmin om feilen, og be personen teste
- nyere versjoner og/eller å skrive en feilrapport
-
-- sysadmin/feilrapportør
-
- - Hvis du finner en feil
- - søk i bug-databasen til produktet om dette er en kjent feil
- - hvis ikke, test siste utgave lokalt
- - hvis feilen fremdeles er der, og er gjenproduserbar, send en
- feilrapport
- - hvis feilen ikke er fikset, men utviklerne er klar over denne,
- send en feilrapport til!
- - sørg for at feilrapporten inneholder nødvendig informasjon for å
- gjenprodusere feilen og hvordan systemet ditt er konfigurert
- - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome),
- perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller
- produktets feilrapporterings-webside (bugzilla, request-tracker,
- gnats e.l. Se på prosjektets hjemmeside)
- - husk å følge opp feilrapporten din
-
-
-- patch-bidragsyter
-
- - Hvis du har muligheten til å rette feilen selv, pass på fortelle
- prosjekt-delagerene om fiksen
- - lag en patch! (patch -u fil.org fil.ny > minfiks.patch)
- - send denne til utvikler-mailinglisten, og følg med om den blir
- inkludert, eller om den krever mere fiksing.
- - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse
- patchen så den blir akseptert.
- - "glemte" patcher _vil_ skape merarbeide for deg neste gang
- programmet skal oppgraderes.
-
-
-- aktiv prosjektdeltager
-
- - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
- _har_ et feilrapportsystem, ikke sant?)
- - Test og gi tilbakemelding på rapporterte feil.
- - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
- denne (så slipper du ekstraarbeide)
- - sørg for at kildekoden du lager er selvdokumenterende, følger
- kode-policy og har akkurat nok kommentarer til at formålet med
- koden er lett å forstå
-
-- prosjektleder
+ <p>I got this idea for a piece of software...</p>
+
+ <ul>
+
+ <li>reuse when possible, prefer to improve existing
+ projects</li>
+
+ <li>read other peoples code, download and test other peoples
+ programs</li>
+
+ <li>understand software licenses
+
+ <li>consider sourceforge
+
+ </ul>
+
+ <p>This software suck. A lot! - Do not take it personally.</p>
+
+ <h2>Use the best free development tools available</h2>
+
+ <ul>
+ <li>compile with lots of warnings
+ <li>use existing libraries, but avoid to many dependencies
+
+ <li>learn to use debugging utilities (gdb, ddd, dmalloc,
+ valgrind, strace, ltrace, electric fence, fncchk, etc)
+ <li>learn to use profiling tools (kprof, gprof, etc)
+ <li>write automatic self testing
+
+ <li>do automatic coverage testing to check the quality of the
+ self test
+
+ </ul>
+
+ <h2>Running a successful free software project I</h2>
+
+ <ul>
+
+ <li>be responsive to comments and suggestions
+ <li>write down where you want the project to go
+ <li>do not accept every change. make sure you like it first
+
+ <li>let everyone work on the things that interests them, use the
+ carrot, as you have no whip
+ <li>set up and use a bts
+
+ </ul>
+
+ <h2>Running a successful free software project II</h2>
+
+ <ul>
+
+ <li>create web pages for your project, include screen shots, a
+ short summary and who to contact for more info
+
+ <li>remember to include a README file in the tarball. it should
+ include the home page URL, the download site URL,
+ a short description of the project and where to send bug reports
+ and patches</li>
+ <li>involve the public mailing lists in the decision making
+ <li>automate everything
+
+ <li>set up system for public review of changes (anonymous CVS,
+ commit emails)
+ <li>communicate the intention behind the choice of license
+ </ul>
+
+ <h2>As the project grows larger</h2>
+
+ <p>Leading by example is your only option.</p>
+
+ <ul>
+
+ <li>communicate the project plan to all project members
+ <li>try to reduce friction and avoid hard language
+ <li>keep track of what everyone is working on
+ </ul>
projects / homepage.git / blobdiff