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

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:tools-development-bounces@ietf.org]
> On Behalf Of Alissa Cooper
> Sent: Wednesday, June 26, 2019 4:24 PM
> To: IETF Tools Development <tools-development@ietf.org>
> 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
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-development