(Early → easier to set up repository, Later → marketing committee can be involved, see mailing list for discussion)

Approved Resolution 7 (TSC 08/08/2019):

To start, a proposal should come with a temporary "code name" (e.g. a geographical location) that can be used for the repository with low risk of trademark violation. On approval, the marketing committee will work with the proposers to create a long term name and will do all the necessary checks. The repository name can be changed.


  • No labels

3 Comments

  1. Arnaud J Le Hors


    • Proposed/Draft Resolution 7:

      Option 1: Ask the marketing committee to pre-approve a list of names that are catchy and not descriptive.

      Option 2: Two phases for naming, the proposal comes with a temporary "code name" (e.g. a geographical location) that can be used for the repository with low risk of trademark violation. On approval, the marketing committee works with the proposers to create a long term name and does all checks. The repository name can be edited.

      Baohua Yang

      Agree with [Option 2]. The author can negotiate with the marketing team with a valid name, and then get approval by TSC.


      Arnaud J Le Hors

      I don't think [Option 1] is practical. At least in some cases projects first start as a lab. We clearly don't want to ask the marketing committee to name every lab being created. And even if we did, I expect they would quickly answer: no, thanks! (smile)


      Arnaud J Le Hors

      Even though [Option 2] involves a bit of a pain I think that's the most practical option.


      Hart Montgomery

      I'm more of a fan of giving the marketing committee "veto power," which I think is what this effectively amounts to.    


      Ry Jones

      We do this internally at LF. FD.IO was Project Rotterdam, IIRC.


      Vipin Bharathan

      There has been no major problems with names yet. There has to be a back and forth with the Marketing Community, the sponsors and others before the project is brought into the picture. Just the way it is happening now. Even sub-optimal names got through the process. This should be a collaborative effort, not just left to Marcomm.


      1. Arnaud J Le Hors

        Given that the issue was brought up by Brian/the LF team, I assume they did see some problems they are trying to mitigate. But in any case everyone who has spoken up so far seems to agree on Option 2. Unless I hear anybody disagree I think we can make that the proposed resolution.


      2. Shawn Amundson

        The preference should be to retain the name that the developers have given the project. Especially if it has existed in labs and the name is good, it would be beneficial to keep it.

        The MC's role should be to vet and provide due diligence around proposed names. It would be best if the MC could weigh in on these topics prior to the proposal, because doing it post-acceptance does two things: a) provides pressure to come up with the name quickly (days, not months); and b) delays a lot of other HL activities that occur upon acceptance of the project (basically anything that requires the name, including repos, etc.). The MC should have a checklist of things that they look into (trademark violation, problems with the name in some languages, etc.).


  2. Hart Montgomery

    I like the text as is.

    As Shawn points out, it would be best if communication with the MC started before the proposal was approved.

  3. Dan Middleton

    I've just requested review from the MC chair.