Subject: [TOOLS-DEVELOPMENT] Making SOWs accessible to a broader pool

From: Alissa Cooper <[email-masked]>
Date: Wed, 26 Jun 2019 16:23:54 -0400

I’m wondering if there are some steps we could take to write our SOWs in such a way as to make them accessible and understandable to a broader pool of potential bidders. I’ve noticed that recent ones tend to use a lot of IETF-specific jargon and acronyms without explanation and assume significant familiarity with the existing infrastructure and code base. Might it be possible to develop some boilerplate text that could be re-used across datatracker-focused RFPs that provides an introduction to the IETF, an introduction to the project, a description of the technologies in use, and links to the source code and other relevant information? 

Thanks,
Alissa

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Jun 2019 16:31:45 -0400

I agree that we want to make these "bidable" by the largest possible audience.  That said, some of them are easier to do without IETF jargon than others.  In all cases we have been including pointers to the code itself, which reall does help a potential bider understand the size of the application and where the enhancement fits.

Russ

> On Jun 26, 2019, at 4:23 PM, Alissa Cooper <[email-masked]> wrote:
> 
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 27 Jun 2019 01:47:33 +0000

Hi!

I agree with Alissa's assessment about the lack of accessibility in the current text.  I only have a sample size of reading exactly one SOW (the Automatic Agenda Builder under discussion) so I can't frame my comments below relative to anything I've seen in the past.

IMO, someone without deep engagement with the IETF (infrastructure or community processes) would have a lot of trouble understanding what this SOW is about.  Could they figure it out, sure -- all of the information is there.  However, have we made it enticing enough that it's worth the effort -- that's my concern.  I don't have a sense of whether we're wading through too many bids and don't know how to down-select; or typically one or two best case.  To project the challenges from my day job, I'm guessing the latter.  Am I wrong?

I think the proposed boiler-plate area identified below are a good idea.

I don't know how applicable this feedback is beyond this SoW (as I said, I haven't seen the others) ...

** Per the Deliverables:
-- Is it assumed that it will be a waterfall delivery process? Or will there be sprints/incremental drops of functionality?
-- I would have expected more guidance on what tech stack the contractor MUST use (e.g., is the GUI supposed to be browser web app? Could the scheduling back-end be in COBOL/language not in our current stack)
-- are there deadlines for completion; a schedule to start

** Per the Contractor Instructions (also read for the first time), I was expecting to see language about:
-- an acceptance testing process -- the contractor says they are done, but how does the customer validate that it is done?
-- secure development lifecycle activities
-- documentation
-- guidance on end-user platform constraints (e.g., if it’s a web app, it should work on xx browsers)
-- POCs
-- packaging (e.g., rpm/deb scripts; container config)

** Swap the Objective and Deliverable sections.  The top-level overview in the Objective is a more gentle opening to the materials.

Again, the new guy so I'm not sure how much of this is old ground.

Roman

> -----Original Message-----
> From: TOOLS-DEVELOPMENT [mailto:[email-masked]]
> On Behalf Of Alissa Cooper
> Sent: Wednesday, June 26, 2019 4:24 PM
> To: IETF Tools Development <[email-masked]>
> Subject: [TOOLS-DEVELOPMENT] Making SOWs accessible to a broader pool
> 
> I’m wondering if there are some steps we could take to write our SOWs in
> such a way as to make them accessible and understandable to a broader
> pool of potential bidders. I’ve noticed that recent ones tend to use a lot of
> IETF-specific jargon and acronyms without explanation and assume
> significant familiarity with the existing infrastructure and code base. Might it
> be possible to develop some boilerplate text that could be re-used across
> datatracker-focused RFPs that provides an introduction to the IETF, an
> introduction to the project, a description of the technologies in use, and
> links to the source code and other relevant information?
> 
> Thanks,
> Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 27 Jun 2019 11:47:23 -0400

> On Jun 26, 2019, at 4:31 PM, Russ Housley <[email-masked]> wrote:
> 
> I agree that we want to make these "bidable" by the largest possible audience.  That said, some of them are easier to do without IETF jargon than others.  

To be clear, I think it’s fine to use jargon as long as it is explained upon first use. I doubt these would make any sense if we tried to avoid jargon altogether. ;-)

Alissa

> In all cases we have been including pointers to the code itself, which reall does help a potential bider understand the size of the application and where the enhancement fits.
> 
> Russ
> 
>