This is an annotated version of the checklist at openjs-foundation/project-status#36, specific to Electron's current state. Once completed, I will respond in that issue with the completed checklist which will then (hopefully!) be passed to the CPC for approval. If completed, I can't foresee any non-trivial roadblocks.

• Adopt the OpenJS Foundation Code of Conduct
  • electron/electron#23137
• Update project CoC reporting methods to include OpenJS Foundation escalation path doesn't need to be done :)
  • note from @bnb: There does not seem to currently be clear and documented guidance on what this is, how to implement it, or what it fully entails from the OpenJS Foundation CPC. There is work being done to improve this, but that work is not completed. One specific point - the ability for CoC rulings to be escalated above and outside of Electron's Community and Safety structure to the CoCP group within the OpenJS Foundation for an "appeal" - is something that Electron would likely want to have feedback on.
• #439
  • @groundwater owning working on the Foundation with this.
• Identify and document other core project infrastructure
  • document by @codebytere: https://hackmd.io/@codebytere/rk2-IRPaL
• Add or Update Governance.md document (required for Impact stage)
  • In speaking with @jorydotcom and @brianwarner, it seems that the electron/governance repo is sufficient for this.
• Confirm required files in place (CODE_OF_CONDUCT.md, LICENSE.md)
  • Documented in the repositories list: electron/governance
• Project Charter is published on website or github
  • electron/governance/charter/
• Update legal copyright notice on project website and github
  • electron/electronjs.org-old#3895
  • TODO: merge on join
• Add OpenJS Foundation logo to project website
  • electron/electronjs.org-old#3895
  • TODO: merge on join
• Add Project logo to OpenJS Foundation website; update PROJECTS.md file
• If project is using crowdfunding platforms, add disclaimer to platforms
  • About section of the Electron OpenCollective
• #440
  • Need update on this from the Foundation / GitHub.
• #441
  • Document decision here, if applicable. Is admin the correct team to update on this?
• Identify individuals from the project to join the CPC
  • Admin / WGs to decide upon joining.
• Document project and foundation contacts for:
  • marketing & social media (listed: Outreach WG)
    • @jdalton
    • @ckerr
    • @bnb
    • @cruzerld
    • @felixrieseberg
    • @codebytere
    • @sofianguy
    • @VerteDinde
    • @MarshallOfSound
    • @erickzhao
  • infrastructure (listed: the people I'm aware of who handle infra for Electron, since there's not an apparent Infra WG)
    • @codebytere
    • @MarshallOfSound
    • @jkleinsc
  • legal/governance help (listed: Admin WG)
    • @mgc
    • @groundwater

Ko su dung

@سلام
احتیاج به 3 نفر متخصص امور بانکی داریم برای مشاوره و حل مسائل،در صورت کمک به مردم جهان پیغام بگذارید

Terribly sorry, can anybody help me close this repositories. Wrong operation to create.

https://github.com/electron/alfred-time

There's a lot of frustration seen in electron/electron#21457 - It seems like an issue that's been allowed to fester for way too long without an satisfactory answer from the Electron team. It could do with some escalation... but to where? Is there a working group that deals with roadmap and perhaps coordinating sponsored feature work, if that's required?

As an OpenJS Foundation project, we need to adopt either the DCO or a CLA (ref: IP_POLICY_GUIDANCE.md).

DCO is annoying and hard. CLA is easier but potentially more of a barrier for some folks.

There's some existing tooling for each:

• https://github.com/probot/dco
• https://easycla.lfx.linuxfoundation.org/#/
  • the preferred CLA tool for the OpenJS Foundation, which they will directly support. If we want to use another tool, we can but they won't be able to help support it. I assume we don't care about that if we choose a different tool.

It looks like we've currently got two somewhat-conflicting issue triage playbooks:

• https://github.com/electron/governance/tree/master/playbooks/responses (from #9)
• https://github.com/electron/governance/tree/master/wg-releases/issue-playbook (from #308)

The content in the first one has had more maintainers submitting changes to it and probably should be the preferred content, but since issue triage is a wg-releases task, the location of the second playbook makes more sense than a top-level directory.

CC @codebytere, @sofianguy, @mlaurencin. I'm inclined to move the contents from the former into the latter and remove the former directory, but thought I'd open an issue to check that I'm seeing this right and not missing some context.

Docs and Tooling Working Group

Externally-focused tooling (e.g. Fiddle, Forge), and Electron documentation across website and electron repo.

Membership

• @HashimotoYT
• @BinaryMuse *
• @ckerr *
• @Kilian
• @malept
• @MarshallOfSound
• @felix
• @miniak

Discussion:

• What are your areas of responsibility?

  • electron-userland?
    • Forge
    • Packager
    • Builder
    • Download
    • electron-installer-*
    • electron-compile
    • osx-sign
  • Tooling
    • `Fiddle
    • Spectron
    • Devtron
    • Typescript Generator
    • Docs Linter
    • Rebuild
    • Quickstart & API Demo repos
    • Update server (update.electronjs.org)
  • Documentation
    • Like the actual docs themselves

• What repositories does that include?

  • ^^ the repos for those projects

• How often should you meet?

  • Bi-weekly

• How will you reach and record consensus?

  • First try to come to consensus
  • Motions pass by Majority (3/4? 2/3?) vote or WG Director approval(?)
  • Record notes in electron/governance

• Should this group be merged with another group?

  • Prob not - some overlap with website, but lots of other responsibilities

• Make sure list of members is correct

  • check

• Initial director suggestion?

  • @ckerr

• Membership requirements

  • Has shown willingness to provide solutions/feedback contributing to docs or tooling.
  • Members should fulfill commitments made or communicate if they cannot be met.
  • Gaining membership into the working group is contigent upon existing consensus rules

• Discussions

  • Should docs and tooling be two separate groups?
    • No, try it out together and adjust if necessary.

Todo Items:

1. Decisions about what governance (if any?) we want to have for userland
   • Also to be discussed at summit?
2. Get a concrete list of repos/areas of responsibility
3. Create WG team and add to governance repo (Michelle) ✅
4. Set up meetings (Michelle) ✅
5. Better versioned docs
   • eg function introduced in version x.x.x; deprecated in x.x.x
6. Docs from TS definitions
7. High level design and component docs/onboarding docs
8. @electron/* modules
9. Combine with outreach working group

I don't know where is the best place to ask electron executives but this repository seems like a good central place.

Apache Cordova is the electron of mobile.
It is a foundational technology that allows developers to write hybrid web apps and to share most of the code with electron and the web, thus having critically high public utility.

Cordova has currently zero paid developper and a lack of maintenance.
Cordova needs contributions to get android 10 support.

I believe Cordova and Electron projects share a common goal of pushing the open web forward.

Electron has quickly got a huge success on the desktop and I expect it's only a matter of a few years until cordova get really popular.
The Electron project has gotten many sponsors, especially Microsoft.

I'm asking for the electron project to sponsor cordova as a friend project, and for electron sponsors, especially Microsoft (which is involved in chromium too with Edge) to give help and funding to this foundational technology.

Details:
apache/cordova#163

The release schedule page hasn't been updated in a while. Is there a new one we should be consulting?

Hello @electron/wg-website 👋

I am the author and one of the maintainers of hubdown, a module for converting markdown into GitHub-style HTML. It's used by electron/electronjs.org, electron/i18n, and help.github.com.

While attempting to help release an update to hubdown so @deermichel can add a special new "Open in Fiddle" feature to the website, I noticed I no longer have admin access to the repo. This project is set up with semantic-release and semantic-pull-requests, so releases should happen automatically. However they're not, as the GitHub token living in Travis CI no longer has the needed GitHub permissions.

A few questions:

• Can I join the website working group?
• Can I have admin access to electron/hubdown?
• What npm user/org do we use to publish to npm these days? cc @MarshallOfSound as I know you worked on some kind of npm 2FA automation...

Thanks!

Hi @electron/wg-website friends 👋

I'd like to request that we move the hubdown project from the @electron org to the @docs org and start publishing it to npm using a GitHub-owned npm account.

I work on the Product Documentation team at GitHub, maintaining help.github.com and developer.github.com. We make extensive use of hubdown and have a vested interest in keeping it updated, bug-free, and performant.

There was recently an effort to automate the npm publishing process for this module using multi-factor auth and semantic-release (thanks @deermichel and @MarshallOfSound!). That worked for a time, but it seems to have stopped working again and I don't have much visibility into the cause. Two weeks ago I landed a PR electron/hubdown#20 to address a bug in the current version of hubdown. This PR was reviewed and merged in short order but unfortunately a new release was not triggered.

Would y'all be open to migrating this module to a new home where it will get more regular attention? We promise to follow SemVer and keep Electron folks in the loop as the project is updated. ✋

cc @sarahs @juliangruber @wooorm

Hi there, i'm currently working on e/hubdown and it would be convenient to being able to push branches directly to the repo instead of forking it. Can i get write access for it? I think a main problem with this repo is that it isn't (officially) governed by anyone rn. Thank you :)

This has been a long running action item to remove folks from the GitHub org that aren't actively part of governance. There are a few reasons for this but it mostly comes down to:

• Security, being part of the org grants access to certain things that we want to keep scoped
• Communication, just being a member of the org gives you a "Member" badge and comments are inherently thought of as "official" whether they are part of governance or not
• Cost, with some features of GHE being limited to org members we don't want to give things like codespaces access to the large quantity of folks that are currently in the org

I'll collect a list of folks I intend to remove and tag them in this issue so they are aware of what is happening.

Folks with guest access to our Slack instance will retain that access, we have no plans to remove guests at this time.

Those who claimed interest at the recent maintainer's summit:

@codebytere
@cruzerld
@felixrieseberg
@groundwater
@jkleinsc
@keeganwatkins
@nornagon
@bnb

This issue is to discuss what the charter and delegated responsibilities of this initiative would be, form the initial set of members, and to produce a proposal for the Admin WG to bless.

// Create a 10MB NormalizedCacheFactory
NormalizedCacheFactory cacheFactory = new LruNormalizedCacheFactory(EvictionPolicy.builder().maxSizeBytes(10 * 1024 * 1024).build());

// Build the ApolloClient
ApolloClient apolloClient = ApolloClient.builder()
.serverUrl("https://...")
.normalizedCache(cacheFactory)
.build();

Electron pull requests

This issue is to discuss forming a Working Group that would be responsible for shepherding Electron's API surface. At the recent maintainer's summit, it was generally agreed that it should be an explicit non-goal of this group to have a member of the WG review every change to APIs. However, the group should be responsible for creating and maintaining the processes by which Electron's APIs are made consistent, stable and developer-friendly.

A non-exhaustive list of examples of discussions that would happen within this group:

• Deprecating & removing the remote module. What should it be replaced with? What's our deprecation pathway?
• Exposing additional IPC primitives, such as transferring file descriptors or Mojo handles.
• Broad API change initiatives like changing get/set to properties.

Those who claimed interest during the maintainer's summit:
@MarshallOfSound
@codebytere
@ckerr
@groundwater
@nornagon
@itsananderson
@Kilian
@loc
@zcbenz
@cruzerld
@miniak
@jkleinsc

2019-02-14 Docs & Tools meeting notes

Discussion

• asar module
  • Has a dependency on node-mksnapshot, which lives in electron-archive, But this dependency has a vulnerable dependency (see: electron/asar#163)
  • Should we remove this feature?
    • Not documented, but shows up in --help
      • Not sure it will even work these days
    • Felix will remove this feature and push a new version
• Fiddle
  • Add a link to the Electron site linking to /fiddle
  • Do we replace the API Demos link with this?
    • Who maintains this? (Mostly Shelley and Michelle just keeping things up to date)
  • Michelle to open issue on the electronjs.org repo to discuss with website WG
• electron-download
  • Should probably support this in core?
  • Maybe something we'll talk about in the userland discussion at summit
    • What is the promotion process for a tool that has gotten so big/popular that it should be officially supported?

Link to meeting-notes folder ( https://github.com/electron/governance/blob/master/wg-administrative/meeting-notes ) gives a 404 when I click it.

Tracking issue to add @PlaineKevin to admin-wg and governance

• Update Permissions
  • https://github.com/electron/.permissions/pull/108
• Add to Governance Docs
  • #460
• @electronjs.org email
• update slack membership
• Community & Safety Approval

According to the governance repo there are several working groups, each of which should be keeping meeting minutes, some never kept any minutes, and the rest have all stopped keeping minutes 1, 2, even 3 years ago. Perhaps the page could be updated to clarify what the current expectations are?

I'm not sure if this was completed or not, but it's one of the final things with #267.

The most critical and decision-heavy areas of work in Electron—releases, security, and upgrades—have working groups dedicated to them. However, several other categories of work require ongoing attention, but don't perhaps merit the overhead of a dedicated working group and don't fall into any of the other major working groups. These categories are:

• API design
• Build infrastructure
• CI
• Performance

None of these areas are clearly the responsibility of any existing working group.

We propose the creation of a working group that would be responsible for technical guidance on matters that do not fall into the responsibility of other existing working groups and do not merit a full working group. This Technical Guidance Working Group would meet on an as-needed basis to resolve issues that arise in the above areas.

Every member of the Electron maintainers group is responsible for making sure that Electron is technically excellent. It is not the intent of this group to allow others to abdicate their responsibility for designing good APIs, fixing CI issues, or improving build infrastructure. The purpose of this group would be to resolve conflicts where they arise and to oversee initiatives related to crafting policy as it relates to the technical direction of Electron.

In electron/mainainers, we used to use issues with labels.

In electron/governance so far, we're using PRs to land minutes in wg-foo/meeting-notes/YYYY-MM-DD.md.

I'm fine with this if it's the consensus approach, but I'd like to confirm that this is a change we're making intentionally than something that Just Happens.

Advantages of using issues:

• Very easy to search / filter notes via github.com
• Fewer steps to open new meeting notes than to PR a meeting notes file
• If minor followups to a meeting are needed, it's easy to add a comment to an issue

I'm not sure if this needs to be done, if some decision was made to keep the status quo, or something else, but it's one of the remaining "open" tasks in #267.