Servo TSC Meeting January 2025

[mrego]

• Date: Monday 27th January 2025 at 16:00 UTC
• Location: https://meet.jit.si/Servo-TSC

Agenda

• Status update
• New self-hosted runners
• Whether to replace unpaired surrogates in the DOM by default
• More coordination on API
• AI policy review
• Outreach
• AOB

[mrobinson]

I would like to add two agenda items:

• Whether to replace unpaired surrogates in the DOM by default:
  • Support surrogates in the DOM? servo#6564
  • https://github.com/servo/servo/wiki/Meeting-2015-07-13#surrogates-in-the-dom
• More coordination on API

[gterzian]

I would like to add one item: lifting the AI ban for Github copilot.

Here is an overview of my position:

Some background:

• Current policy bans all use of AI. I've been experimenting with copilot, and found it useful. But, I have to throw away those commits because of the ban.
• Not only does copilot make me more productive and is it a joy to use, I think using it would also would improve our codebase. Why? Because copilot only works when the code is well documented and based on clear patterns. So copilot gives an incentive to write that kind of code, and it also produces it, which is good for the health of the project.

Below I'll address the various points of the current policy:

• Maintainer burden: in my experience, works best when you copy/paste a line from a specification as doc comment for almost every line of code produced. The suggestions are then based on existing code doing something similar. This means that the resulting code, a mixture of which is generated and hand edited, ends-up following conventions and is well documented: the code is of higher quality to begin with and therefore easier to review.
• Correctness and security: I think correctness and security are for a large part about following existing coding conventions, and copilot excels at it. Also, as the name "copilot" implies, you use it to help you with routine stuff, not to make critical decisions.
• Copyright issues: The code suggestions pick-up on patterns and naming conventions that are specific to the project, so unlikely to come from other code bases.
• Ethical issues: I think this is something not for the TSC, but for individual contributors to decide for themselves. When it comes to copilot, one could for example read the sustainability report for Microsoft and make a choice.

I propose that we lift the ban specifically for Github copilot.

[Manishearth]

Copyright issues: The code suggestions pick-up on patterns and naming conventions that are specific to the project, so unlikely to come from other code bases.

I think there's an additional aspect: potential downstream users of Servo may have policies around this due to an abundance of caution, and may not be able to use Servo maintained libraries if Servo uses Copilot.

[matlu]

Interesting, will this open up a new opportunity for how to use Servo?
Would like to hear the thoughts from other TSC attendees.
Note please watch the video before the call. Video is also on YouTube:
https://youtu.be/C25g53PC5QQ?si=cbg1caIHzIecMNg7

https://www.diabrowser.com/

Come build Dia.
AI won’t exist as an app. Or a button. We believe
it’ll be an entirely new environment — built on top of a web browser.

[gterzian]

Here is a good resource regarding copyright: https://resources.github.com/learn/pathways/copilot/essentials/establishing-trust-in-using-github-copilot/

Both GitHub and Microsoft provide indemnity for their Copilot products.
This framework is based on our confidence in GitHub Copilot’s compliance with IP laws

[gterzian]

@Manishearth Thanks for your feedback above.

I wanted to highlight that the issue has been further discussed, and is now up for a vote, at https://servo.zulipchat.com/#narrow/channel/263399-Technical-Steering-Committee/topic/Another.20look.20at.20AI.