&title;

diff --git a/en_US.ISO8859-1/htdocs/news/status/Makefile b/en_US.ISO8859-1/htdocs/news/status/Makefile index ccdc66f0c8..7562fc1c8a 100644 --- a/en_US.ISO8859-1/htdocs/news/status/Makefile +++ b/en_US.ISO8859-1/htdocs/news/status/Makefile @@ -1,73 +1,73 @@ # $FreeBSD$ .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif -DOCS= status.xml +DOCS= status.xml howto.xml XMLDOCS= report-2001-06 XMLDOCS+= report-2001-07 XMLDOCS+= report-2001-08 XMLDOCS+= report-2001-09 XMLDOCS+= report-2001-11 XMLDOCS+= report-2001-12-2002-01 XMLDOCS+= report-2002-02-2002-04 XMLDOCS+= report-2002-05-2002-06 XMLDOCS+= report-2002-07-2002-08 XMLDOCS+= report-2002-09-2002-10 XMLDOCS+= report-2002-11-2002-12 XMLDOCS+= report-2003-01-2003-02 XMLDOCS+= report-2003-03-2003-09 XMLDOCS+= report-2003-10-2003-12 XMLDOCS+= report-2004-01-2004-02 XMLDOCS+= report-2004-03-2004-04 XMLDOCS+= report-2004-05-2004-06 XMLDOCS+= report-2004-07-2004-12 XMLDOCS+= report-2005-01-2005-03 XMLDOCS+= report-2005-03-2005-06 XMLDOCS+= report-2005-07-2005-10 XMLDOCS+= report-2005-10-2005-12 XMLDOCS+= report-2006-01-2006-03 XMLDOCS+= report-2006-04-2006-06 XMLDOCS+= report-2006-06-2006-10 XMLDOCS+= report-2006-10-2006-12 XMLDOCS+= report-2007-01-2007-03 XMLDOCS+= report-2007-04-2007-06 XMLDOCS+= report-2007-07-2007-10 XMLDOCS+= report-2007-10-2007-12 XMLDOCS+= report-2008-01-2008-03 XMLDOCS+= report-2008-04-2008-06 XMLDOCS+= report-2008-07-2008-09 XMLDOCS+= report-2008-10-2008-12 XMLDOCS+= report-2009-01-2009-03 XMLDOCS+= report-2009-04-2009-09 XMLDOCS+= report-2009-10-2009-12 XMLDOCS+= report-2010-01-2010-03 XMLDOCS+= report-2010-04-2010-06 XMLDOCS+= report-2010-07-2010-09 XMLDOCS+= report-2010-10-2010-12 XMLDOCS+= report-2011-01-2011-03 XMLDOCS+= report-2011-04-2011-06 XMLDOCS+= report-2011-07-2011-09 XMLDOCS+= report-2011-10-2011-12 XMLDOCS+= report-2012-01-2012-03 XMLDOCS+= report-2012-04-2012-06 XMLDOCS+= report-2012-07-2012-09 XMLDOCS+= report-2012-10-2012-12 XMLDOCS+= report-2013-01-2013-03 XMLDOCS+= report-2013-04-2013-06 XMLDOCS+= report-2013-05-devsummit XMLDOCS+= report-2013-07-2013-09 XSLT.DEFAULT= report.xsl # Install a sample entry. DATA= report-sample.xml INDEXLINK= status.html .include "${DOC_PREFIX}/share/mk/web.site.mk" diff --git a/en_US.ISO8859-1/htdocs/news/status/howto.xml b/en_US.ISO8859-1/htdocs/news/status/howto.xml new file mode 100644 index 0000000000..2e320a8a0c --- /dev/null +++ b/en_US.ISO8859-1/htdocs/news/status/howto.xml @@ -0,0 +1,105 @@ + + +]> + + + + &title; + $FreeBSD$ + + + + +

&os; status reports are published quarterly and provide the general + public with a view of what is going on in the Project, and they are + often augmented by special reports from Developer Summits. As they + are one of our most visible forms of communication, they are very + important. This page will provide some advice on writing status + report entries from David + Chisnall, experienced in technical writing.

+ +

Do not worry if you are not a native English speaker. The team + handling status reports, monthly@FreeBSD.org, will check + your entries for spelling and grammar, and fix it for you.

+ +

Introduce Your Work

+ +

Do not assume that the person reading the report knows about + your project.

+ +

The status reports have a wide distribution. They are often one of + the top news items on the &os; web site and are one of the first + things that people will read if they want to know a bit about what + &os; is. Consider this example:

+ +

abc(4) support was added, including frobnicator compatibility.

+ +

Someone reading this, if they are familiar with UNIX man pages, + will know that abc(4) is some kind of device. But why should + the reader care? What kind of device is it? Compare with this + version:

+ +

A new driver, abc(4), was added to the tree, bringing support for
+Yoyodyne's range Frobnicator of network interfaces.

+ +

Now the reader knows that abc is a network interface driver. Even + if they do not use any Yoyodyne products, you have communicated that + &os;'s support for network devices is improving.

+ +

Show the Importance of Your Work

+ +

Status reports are not just about telling everyone that things + were done, they also need to explain why they were done.

+ +

Carry on with the previous example. Why is it interesting that we + now support Yoyodyne Frobnicator cards? Are they widespread? Are + they used in a specific popular device? Are they used in a + particular niche where &os; has (or would like to have) a presence? + Are they the fastest network cards on the planet? Status reports + often say things like this:

+ +

We imported Cyberdyne Systems T800 into the tree.

+ +

And then they stop. Maybe the reader is an avid Cyberdyne fan and + knows what exciting new features the T800 brings. This is unlikely. + It is far more likely that they have vaguely heard of whatever you + have imported (especially into the ports tree: remember that there + are 20,000 other things there too...). List some of the new + features, or bug fixes. Tell them why it is a good thing that we + have the new version.

+ +

Tell Us Something New

+ +

Do not recycle the same status report items.

+ +

Bear in mind that status reports are not just reports on the status + of the project, they are reports on the change of status of the + project. If there is an ongoing project, spend a couple of + sentences introducing it, but then spend the rest of the report + talking about the new work. What progress have been made since the + last report? What is left to do? When is it likely to be finished + (or, if finished does not really apply, when is it likely to + be ready for wider use, for testing, for deployment in production, + and so on)?

+ +

Open Items

+ +

If help is needed, make this explicit!

+ +

Is there any help needed with something? Are there tasks other + people can do? There are two ways in which you can use the open + items part of the status report: to solicit help, or to give a quick + overview of the amount of work left. If there is already enough + people working on the project, or it is in a state where adding more + people would not speed it up, then the latter is better. Give some + big work items that are in progress, and maybe indicate who is + focussing on each one.

+ +

List tasks, with enough detail that people know if they are likely + to be able to do them, and invite people to get in contact.

+ +

Back to the main page

+ + diff --git a/en_US.ISO8859-1/htdocs/news/status/report-sample.xml b/en_US.ISO8859-1/htdocs/news/status/report-sample.xml index d37d9c3651..a4b0229af6 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-sample.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-sample.xml @@ -1,51 +1,61 @@ Status Report Sample + John - Smith test@FreeBSD.org + + + + Wunderteam + + team@FreeBSD.org + Description here. -

You can start your first paragraph here. Generally speaking, you - will only usually submit one paragraph per status report, as they - are intended to be somewhat brief. If, however, you find it - necessary to write one with multiple paragraphs, it's fairly - straightforward.

+ +

Introduce your work. Do not assume that the person reading the + report knows about your project.

+ +

Show the importance of your work. Status reports are not just + about telling everyone that things were done, they also need to + explain why they were done.

Just start another `p' tag.

What has happened since the last report? Let us know what is new + in this area.

- Some work you need help with - More work - Keep these short and to the point + If help is needed, make this explicit! + List tasks, with enough detail that people know if they are + likely to be able to do them, and invite people to get in + contact. - diff --git a/en_US.ISO8859-1/htdocs/news/status/status.xml b/en_US.ISO8859-1/htdocs/news/status/status.xml index e90d4899b5..0dd763da73 100644 --- a/en_US.ISO8859-1/htdocs/news/status/status.xml +++ b/en_US.ISO8859-1/htdocs/news/status/status.xml @@ -1,222 +1,225 @@ ]> &title; $FreeBSD$

Next Quarterly Status Report submissions (October — December) due: January 14th, 2014

Use the xml generator or download and edit the xml-template. Submissions should be submitted by e-mail to monthly@FreeBSD.org.

One of the benefits of the FreeBSD development model is a focus on centralized design and implementation, in which the operating system is maintained in a central repository, and discussed on centrally maintained lists. This allows for a high level of coordination between authors of various components of the system, and allows policies to be enforced over the entire system, covering issues ranging from architecture to style. However, as the FreeBSD developer community has grown, and the rate of both mailing list traffic and tree modifications has increased, making it difficult even for the most dedicated developer to remain on top of all the work going on in the tree.

The &os; Development Status Report attempts to address this problem by providing a vehicle that allows developers to make the broader community aware of their on-going work on FreeBSD, both in and out of the central source repository. For each project and sub-project, a one paragraph summary is included, indicating progress since the last summary. If it is a new project, or if a project has not submitted any prior status reports, a short description may precede the status information.

For more exact guidelines on how to write good status reports, + please consult our recommendations.

Periodically special status reports are also prepared and published. One of those are the developer summit reports. Developer summits are places where developers meet in person to discuss issues related to the project. They are definitely worth attending if one is interested in making significant contributions to the Project and they are open to anybody!

These status reports may be reproduced in whole or in part, as long as the source is clearly identified and appropriate credit given.