forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <s...@enbaya.co.za>
Subject Re: Writing our guidelines by use-cases
Date Tue, 20 Jul 2004 10:14:00 GMT
On Tuesday 20 July 2004 12:02, Thorsten Scherler wrote:
> I now can understand better that e.g. documentation
> can always go into SVN seeing that other committer will pick it up and
> helping to fix it. This committer would not be able to help if the
> document is still *only* on my local harddrive.

While I am not contributing to the project, I do contribute to other projects. 
As a documentation contributor to Open Source projects, I can say that the 
best thing you can do is to commit your work. It's of no use to anyone when 
it is sitting on your hard drive.

Do small parts of the document, say section at a time, then commit. This will 
enable others to help you and will speed progress of the total documentation 
development. Before you go hacking away, try to get an outline and commit 
just that. Explain where the document will fit into the greater picture of 
the projects documentation (don't duplicate). Then discuss it with members.

If they make changes or additions it will be good since they have shown that 
they are taking interest and share ownership of the documents development. 
Generally you will find that specific people will talk to you about only the 
parts they are working on or for which they could be considered a subject 
matter expert. This is good. Since once you know who the SME is you can save 
time by speaking to the person only on that point. They will also save time 
as they don't need to check the whole document, only that which is important 
to their area. In big projects it is also helpful if you modularize your 
source so that people can work on specific parts without adding confusion and 
having to resolve conflicts all the time.

Once this is done, then select sections you will be working on. Try to work on 
sections that others are not working on. Again, work small, commit often. If 
you modularize then you can generally work on a sect in one module, commit 
and wait for response while working on a section of another module. So 
allowing people time to collaborate. If you are not sure what to do with 
regard to committing patches then ask one of the devs if you can send them 
the patch to review and and commit. I am assuming you already know how to 
diff and create patches against the repository. If not let me know offlist 
and I will help.

Hope this helps.

-- 
Sean Wheller

Mime
View raw message