Proposal for a new "Documentation Management" group

[Wierd_w]

Just an idea to kick around--
With the recent issues of reverse engineering, and our
new-- extra stern-- IP policy, it appears that
"cleanroom implementation" (US style) is going to be
very strictly adhered to.  This raises a few concernes
to me, even though I dont develop code.
1) The developers that decide they will become(Stay)
reverse-engineers are going to have a great deal on
their plate allready. Not only will they have to
decompile proprietary binaries, but they will also
have to make documentation about the functions within
those binaries.  Asking them to manage the collective
work of both themselves and other reverse engineers is
asking too much.
2) Implementors are not allowed to have direct
communication with reverse engineers, under US style
CleanRoom implementation practices.
So, I propose a new group classification, with the
purposes of
1) Organizing, catalogueing, and possibly correcting
(For spelling, and other grammaticals) the whitepaper
documentation produced by the reverse engineers.
2) Offering the functional service of communicating
with the reverse engineers any objections, or concerns
the implementors might have. (EG, "XXXX XXXX does XXX
XXX by YYYYY" is not sufficent to explain what is
going on, can I get a better description?", the
documentation manager group would contact the reverse
engineer in question, and ask them to make an adendum
to their documentation to address this issue, and
would then contact the implementor after such
addendum(s) have been completed, and filed.)
This group would thus have responsibilities simmilar
to "Editor", "Librarian", and "Secretary", which is
why I propose the generic name "Documentation
Manager(s)."
If there is allready such a position/group, I withdraw
the proposal. Otherwise, I dont see how we could
really hope to pull this off without dedicated
individuals on this task.
(PS, having "non-Coders" on this taskforce would
probably alleviate any allegations of contamination
between reverse engineers and Implemntors, in that it
is unlikely that the secretary in question would
understand a very technical request to begin with, and
thus be unable to pass on any such complicated
requests in their duties as secretary. It would also
give some really strong enthusiasts something to do--
All you need are clerical and communication skills.)
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Jerry]

This is one the best Ideas I've seen for this poject. I second it.
Wierd_w wrote:
>  Just an idea to kick around--
> With the recent issues of reverse engineering, and our
> new-- extra stern-- IP policy, it appears that
> "cleanroom implementation" (US style) is going to be
> very strictly adhered to.  This raises a few concernes
> to me, even though I dont develop code.
> 1) The developers that decide they will become(Stay)
> reverse-engineers are going to have a great deal on
> their plate allready. Not only will they have to
> decompile proprietary binaries, but they will also
> have to make documentation about the functions within
> those binaries.  Asking them to manage the collective
> work of both themselves and other reverse engineers is
> asking too much.
> 2) Implementors are not allowed to have direct
> communication with reverse engineers, under US style
> CleanRoom implementation practices.
> So, I propose a new group classification, with the
> purposes of
> 1) Organizing, catalogueing, and possibly correcting
> (For spelling, and other grammaticals) the whitepaper
> documentation produced by the reverse engineers.
> 2) Offering the functional service of communicating
> with the reverse engineers any objections, or concerns
> the implementors might have. (EG, "XXXX XXXX does XXX
> XXX by YYYYY" is not sufficent to explain what is
> going on, can I get a better description?", the
> documentation manager group would contact the reverse
> engineer in question, and ask them to make an adendum
> to their documentation to address this issue, and
> would then contact the implementor after such
> addendum(s) have been completed, and filed.)
> This group would thus have responsibilities simmilar
> to "Editor", "Librarian", and "Secretary", which is
> why I propose the generic name "Documentation
> Manager(s)."
> If there is allready such a position/group, I withdraw
> the proposal. Otherwise, I dont see how we could
> really hope to pull this off without dedicated
> individuals on this task.
> (PS, having "non-Coders" on this taskforce would
> probably alleviate any allegations of contamination
> between reverse engineers and Implemntors, in that it
> is unlikely that the secretary in question would
> understand a very technical request to begin with, and
> thus be unable to pass on any such complicated
> requests in their duties as secretary. It would also
> give some really strong enthusiasts something to do--
> All you need are clerical and communication skills.)
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>