|
On 8/30/2019 3:39 PM, Sarah Banks
wrote:
Hi Mike,
Some
thoughts, inline. Speaking for myself. SB//
Not really. Seriously - you're the author of the SOW with the
RSOC so this is direct commentary on your work product.
Five immediate large
items:
0) The requirements for
this position are pretty much indistinguishable from
that of the RSE as stated in previous versions of
the SOW. I don't think that makes sense. If this
is simply a "we want to hire some short time to do
the RSE position", then state that rather than using
the figleaf of strategic and tactical. I'm not
saying you'll get community buy-in for that, but at
least it would be less obfuscated.
SB// The thought here was as intended; specifically on
tactical, and nothing more. It IS focused on what the
current RSE does tactically - I'm not sure how we change
that until the community has a conversation about the
role. I'm all ears and open to suggestions, though!
I don't think you've actually thought through the tactical items
well enough for the community to give you a thumbs up or down.
So some additional questions:
a) Does this contract end with the RSE contract is let?
b) Does the RSE regain most of the tactical stuff?
c) If so, there's an end product that needs to be requested -
the hand-over documentation.
d) Does acting as the tactical person prevent you from
bidding on the RSE? If not, why not? [E.g. insider knowledge vs
fairness of the bid process]
e) Can you think of any of these items to eliminate as "can
wait for an RSE"? If not, then see my original question (0).
1) Is this a full time
position? If not, then describe the expected
workload. From the description, its a level of
effort contract somewhat less than full time. State
that level.
SB// The RSOC in years past has specifically stayed out
of the "how long does it take to do the job" and the "this
is a 32-hour-a-week" job. I'd defer this to the LLC; if
the person they're hiring is a contractor I'm not sure
this matters, since they're bidding on the total amount of
work (that's been the thought) versus the employee who
clearly needs to understand if this is a part time or full
time job.
I can't see how this could be let as a firm fixed price contract
or even a piece work or deliverable task contract. I think this
is an LOE contract with meta deliverables. You're going to want
some of this persons time to be committed, and you're going to
want to tell them up front what that time commitment is. I think
figuring out what that LOE is is squarely in the wheelhouse of the
SOW authors.
2) The style manual (last
bullet) is a strategic item, not a tactical item.
Delete it.
SB// I could live with this, thanks.
3) Matrix management -
seriously? That's how we got to this situation in
the first place.
SB// We understand that's a concern, and it should
probably be one of the items we discuss as a community.
We're not looking to force the process though, and to that
end, using the process we have (this language came from
the previous SOW we used, in fact) seemed prudent. Given
that they're focused on the RPC and the new format work
and reporting to the RSOC, how else would you propose we
address your concern?
4) Term - for a
tactical contract, this is pretty long - 1.5 years
with the possibility of a year extension.
SB// As I previously explained, we as a community don't
tend to have short conversations. The process will take
time. If we conclude in less than 1.5 years then
fantastic, we'll have some overlap with whatever outcome
we get from that discussion and the current/temporary RFC
Series Project Manager. That seems like an acceptable
thing to me.
Small items:
1) Drop the "Experience
as an RFC editor" bullet in favor of "Familiarity
with the RFC series is desired but not required".
2) The "culture and
process" bullet is also strategic and not
tactical. Drop this to just the RFC process.
3) Travel internationally
- state if this is in addition to the IETF meetings.
SB// These seem reasonable.
Overall comment:
This has the feel to me
of a push towards a more "managed" RFC Editor vs the
independent model we've had over the lifetime of the
series - and doing it by small nibbles and by
delay. The RFC++ bof indicated community
displeasure with that direction, and I'm not sure
this SOW is representative of community desires.
I'd be happier with this if the sole and only
contract reporting link is from this contractor to
the LLC. The LLC MAY appoint the RSOC for day to
day things, but any contractual discussions OF ANY
KIND should be with the actual organization that
holds the contract. From a community point of
view, we have oversight and a direct line of
responsibility from the LLC to the community (with
the concomitant ability of the community to recall
or otherwise fail to reappoint LLC board members) .
That is not the case with the RSOC.
With respect to the
evolution of the RFC Series - I haven't seen any
clear statement from anyone of the changes they
believe need to be made. So, prior to putting us in
the penalty box for a year and a half, perhaps we
could actually get a statement of interests which
would indicate that we need such a delay in the RFC
SE selection process. E.g. a full formal ID/RFC
not random musings in email with enough initial
support that we have the possibility of getting to
some sort of consensus for change if we invest the
time.
SB// The goal is to have the conversation as a group,
and figure out what to do. if we don't want a managed RFC
Editor, but the independent model that folks believe we
should have, then as a community we should say that, and
figure out how to instrument what we want. Personally, I
like the spirit of what was described to me starting with
Postel, and having some independence from being told what
to do blindly with the ability to push back doesn't seem
to be a bad thing. But that's my personal thought, and as
an RSOC it's not our current purview to tell the community
what to do.
I agree, however, the RSOC seems to have taken it as a purview to
diminish the independence of the RSE from previous levels. If the
RSOC (and for that matter) would take a look at what it was fall
of 2016 vs how its been behaving vis a vis the RSE since that
point in time, I'd be much happier with your statement that you
don't tell the community what to do.
We're trying to strike a balance between the process
we have, which keeps our contractors moving and documents
flowing, and allowing the community to do its thing. This
position "reporting" to the LLC makes little sense to me -
1. that's not the current process we have (and if you
don't like it, speak up and change it, Ted's outlined how
we might proceed to doing that) and 2. The LLC really
isn't equipped to handle it either.
See my note to Stephen. Basically, I think it may be OK to have
the RSOC operate as a COTR under the purview of the LLC with no
ability to tell the RSE what to do, but instead acts as an advisor
to the LLC for contract issues. That gives whoever gets hired one
and only one point of control to deal with. I'd also suggest
that the RSOC no longer do the "we're talking about contracts in
executive session" stuff and instead call for community input
every couple of years or so and write a public report detailing
pros and cons based on that input (and specifically no anonymous
input) as the basis for the LLC to make its decisions. 6635 is
not controlling on the LLC as they are the fiduciaries - but the
community might not like that interpretation. They could adopt
6635 as an operating instruction by vote of the board, but I don't
see that as having taken place.
The RSOC seems to be the reasonable choice given the
situation we find ourselves in, and again, this is a 1.5
year contract with clearly described goals.
"clearly described goals" is overstating it I would say. Sorry.
Mike
We'll have the conversation to change (or not) - in the
grand scheme of things, this doesn't seem to be an issue
to me. The alternatives concern me more - do we just not
have an RSE-like function at all, in any capacity, being
executed, while we chat as a group? No documents are
published? We're paying for the RPC function by contract
now; I'd like to see our money well spent, personally. I'm
not sure I understand the analogy to a penalty box, but if
you mean we're in a holding pattern until we figure out
what we want then yes, I totally agree, we are, and I
don't see a better alternative. I'm happy to discuss any
alternatives you might have.
/S
Later, Mike
On 8/30/2019 12:38 PM,
Sarah Banks wrote:
Hello,
The
RSOC has received a lot of feedback regarding the
current SOW, in addition to the feedback received
generally around the RSE role, both on and off
list, and at the microphone at the plenary session
in Montreal. We've listened, discussed, and come
up with a proposal that you'll find attached here.
Broadly
speaking, the RSE role contains 2 functions, a
strategic function and a tactical function. We
believe that we, as a community, still want RFCs
published while we discuss the RSE role evolution.
We also have a contract in place with the RPC
(both Production Center and Publisher), both of
whom are accustomed to a day to day contact to
lean on for assistance (the current RSE).
With
that in mind, we are proposing a temporary
position that focuses on the tactical components
of the current RSE role, with 2 large work items
in mind.
First,
this temporary position (called the Temporary RFC
Series Project Manager) would serve as the day to
day contact for the RPC, assisting with tactical
items.
Second,
this role would focus on the v3 format work,
assisting with the delivery of the new tools for
the format work, and bringing the new format work
to a close.
Details
are included within the SOW, attached with this
email.
The
IAB plans on sharing a follow up email shortly,
that covers possible next steps for the strategic
portions of the RSE role and the evolution
discussion.
We'd
like to open a 2 week comment period on the SOW,
starting on August 30, 2019, closing ons on
September 14, 2019. Please send your comments and
feedback to the RSOC ( rsoc@xxxxxxx).
Kind regards,
Sarah Banks
For the RSOC
_______________________________________________
rfc-interest mailing list
rfc-interest@xxxxxxxxxxxxxx
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
|
