Hi,
Each of the RPM packages in Fedora have descriptions in their spec files and while many of them are good, there are quite a few ones that are vague and not descriptive enough.
I think the documentation team should look into this and maybe review guidelines can include a sign-off from someone in the documentation team to verify the quality of the descriptions.
This is also very good for new contributors to participate (along with kbase.fedoraproject.org when it's launched) and help out without any long term commitment involved.
Comments?
Rahul
On Wed, 2007-10-31 at 01:08 +0530, Rahul Sundaram wrote:
Hi,
Each of the RPM packages in Fedora have descriptions in their spec files and while many of them are good, there are quite a few ones that are vague and not descriptive enough.
I think the documentation team should look into this and maybe review guidelines can include a sign-off from someone in the documentation team to verify the quality of the descriptions.
This is also very good for new contributors to participate (along with kbase.fedoraproject.org when it's launched) and help out without any long term commitment involved.
Comments?
That's an idea that has been kicking around RH docs folks for a while, but hasn't gone anywhere so far. Seems like a great time to see it through to completion!
I agree with you, and also have had the experience of waiting for the long haul to get a few lines changed in a RHEL package info. By doing it as part of an overall process, we are more likely to see real changes made.
There are two basic ways:
1. New tooling + human process 2. Human process
We might be able to do number 2 without too much pain. One question is, how to get the change(s) committed to the package's SCM? What role for Bugzilla in this?
I can imagine good requirements but what tool can could fill them? Something like Transifex for spec instead of PO/POT files. :)
- Karsten
Karsten Wade wrote:
On Wed, 2007-10-31 at 01:08 +0530, Rahul Sundaram wrote:
Hi,
Each of the RPM packages in Fedora have descriptions in their spec files and while many of them are good, there are quite a few ones that are vague and not descriptive enough.
I think the documentation team should look into this and maybe review guidelines can include a sign-off from someone in the documentation team to verify the quality of the descriptions.
This is also very good for new contributors to participate (along with kbase.fedoraproject.org when it's launched) and help out without any long term commitment involved.
Comments?
That's an idea that has been kicking around RH docs folks for a while, but hasn't gone anywhere so far. Seems like a great time to see it through to completion!
I agree with you, and also have had the experience of waiting for the long haul to get a few lines changed in a RHEL package info. By doing it as part of an overall process, we are more likely to see real changes made.
There are two basic ways:
- New tooling + human process
- Human process
We might be able to do number 2 without too much pain. One question is, how to get the change(s) committed to the package's SCM? What role for Bugzilla in this?
1) For new specs going forward, introduce a mandatory sign-off from the documentation team. It wouldn't take more than say 10 minutes for every review and anyone interested could do it even as a one off process.
2) For existing specs, get involved in the merge review if it exists or go through them one by one and file RFE's in bugzilla for any corrections. Set Fedora 9 as the deadline to review existing packages. Sources packages are around 5000. Should be doable I think.
It is possible to enhance this with more tools but that is usually a long term thing as we have seen with the plone discussions.
Rahul
docs@lists.stg.fedoraproject.org