RE: Please comment on your use of trac

["STARK, BARBARA H" <[e-mail]>]

Hi Rob,
 
> Hi Barbara, Jay,
> 
> >
> > > I’m in the process of drafting the RFP for this work and I want to check
> > a few
> > > things base on your replies:
> > >
> > > 1.  It sounds as it everyone is comfortable with a migration to a new
> > wiki system
> > >
> > > 2.  A few WGs - EMAILCORE, DMARC and TSVWG are using trac for issue
> > > tracking and need migrating to a new issue tracker.  Would you be happy
> > if that
> > > was GitHub? (DMARC has already indicated this is acceptable).
> > >
> > > 3.  Many more WGs used to use trac for issue tracking but no longer do.
> > We
> > > need to find a way to archive these for the historical record, but I
> > want to check
> > > you would be happy if that was just an export to a text file that could
> > then be a
> > > wiki page rather than moving them to a new issue tracking system?
> >
> > I'm fine with this, but want to note the private nomcom2020 wiki should be
> > archived in a protected place and not be publicly accessible. It might not
> > be great to have minutes of NomCom deliberations out there for all to see.
> > So, just a request to take care with the archiving. Feel free to consult
> > with me when this is done (I see RFC8713 says the impacted NomCom gets to
> > vote on how to implement an archive). Also, NomCom archives are only
> > required to last for the duration of the NomCom term. So it would be good
> > to be able to delete this archive in the future. Victor may have thoughts
> > on whether he'd like nomcom2019 archived at all, since its term is over. I
> > also see there are nomcom2017 and nomcom2018 wikis. Someone should
> think
> > about these, too. - Barbara
> [RW]
> 
> Doesn't this text in RFC8713 require that the NomCom archive is deleted when it
> is no longer required?
> 
> 5.16.  Archives
> 
>    The NomCom should archive the information it has collected or
>    produced for a period of time but not to exceed its term.
> 
> I don't know what information the NomCom archives contain, but my concern
> here is potential reputational risk to IETF if confidential information ever leaked.
> From a privacy perspective, if the information is longer required, then the safest
> action seems to be to ensure that all copies of any confidential or private data is
> destroyed.
> 
> Regards,
> Rob

I would certainly interpret it that way. But I'm not Chair (and nor was I a member) of a NomCom whose term is over. The 2020 NomCom's term ends in November (the Third IETF of 2021). I think it's for others to decide what to do with the artifacts of prior NomComs. I'm merely noting their existence while asking for the NomCom 2020 artifacts to be appropriately handled through November.
Barbara

> > > 4.  The following features for a new wiki system have been recommended:
> > >
> > > 	* document names resolve to links to the documents without having
> > to
> > > require explicit URLs.
> > > 	* I would like a markdown based wiki system.
> > >
> > > 5.  We are currently considering moving to a *single* wiki instead of
> > multiple
> > > different instances of the same wiki.  The means the following features
> > are
> > > needed to support the various ways that WGs and other groups use their
> > wikis:
> > >
> > > 	• support of OIDC for authentication with Datatracker
> > > 	• permissions system (which will be limited to roles that
> > Datatracker
> > > know about)
> > >
> > > (so far the product that seems to meet these requirements the best is
> > Wiki.js)
> > >
> > > Any comments, or any more to add?
> > >
> > > Jay
> > >
> > >
> > > > On 4/02/2021, at 5:17 AM, Robert Sparks <[e-mail]> wrote:
> > > >
> > > > We currently have instances of trac configured for each working group.
> > Only
> > > some are being used.
> > > >
> > > > If your group is using trac, are you using anything essentially trac-
> > specific that
> > > you find important?
> > > >
> > > > Would you be ok migrating (with help) to a different wiki system and a
> > > different issue tracking system?
> > > >
> > > > The trac project itself is lagging with Python development - stable
> > still only
> > > runs on Python 2.7 and while there appears to be work towards Python 3,
> > it is
> > > not yet functional, and is not progressing quickly. We are working
> > around it by
> > > encapsulating it in docker instances running 2.7.
> > > >
> > > > I've had several people suggest we should stop supporting it, and I'd
> > like to
> > > know if that would be a particular hardship for any group.
> > > >
> > > > RjS
> > > >
> > > >
> > >
> > > --
> > > Jay Daley
> > > IETF Executive Director
> > > [e-mail]