Event: {E3}
---
==Attendees:
- @Matthew
- @dcog
- @dtf
- @speck
- @luca.itro
---
==Agenda Items and Notes:
1. Action item check-in
- @Matthew Discuss banner on {T15012}
- @Matthew Create task and discussion around integrating Askimet.
- @20after4 - Lock down what we can on this install, make notes on what we can't install.
- @20after4 - Create a banner for the frontpage to show people how to contribute (Link to ponder, info on trusted contributors)
- @dcog Investigate Rector: https://getrector.org/
2. Deploying changes
- Chris to make a task in regard to having Harbormaster: {T15092}
2. Rebrand Effort
- Rector comments and discussion
- Concerns over upstream-ability, but seems useful.
- Main concern: Automatic renaming of "Phabricator" to something else is not likely to be accepted upstream. Our current approach outlines first trying to rephrase text to remove the platform name altogether (e.g. refer to simply as "the installation").
- Supports the batch rename process.
- Hold off until the we fully fork from upstream perhaps?
- Renaming
- We need to rebase against upstream to get changes discussed with Evan. Dan to try, but anyone else is welcome to as well.
- There is a tool that can rename the classes dynamically on the fly: https://secure.phabricator.com/T13658#255996 - To be investigated
- Perhaps we use `runkit` to log, then watch on our upstream instance?
- Rebranding would invalidate translations,The rebranding approach of changing the `pht()` keys will invalidate a lot of existing translations. Investigate if there are ways to avoid this.
- It might be possible/reasonable for the rebrand effort to work by adding a new translated language, e.g. "English - Phorge", where none of the `pht()` entries are changed but instead get "translated" to new phrasing that doesn't mention Phabricator. so we need to investigatThis feels a bit hackish but might be a reasonable (short-term?) path forward without breaking existing translations and might be easier to crowdsource.
- Create a new project on TranslateWiki rather than using `Phabricator`?
- Ponder is completed. Keep this more open to community than e.g. Maniphest, so that Tasks are relegated to known work to be done whereas anyone is able to ask questions.
- Liked by team, seems good.
3. Prototype Applications
- @Matthew to collect list of prototype and deprecated applications, make a task for each.
- It would be wise to investigate why each application is prototype, and include on each task.
4. Community Migration
- Arcanist is a pain point, and also tends to be a barrier to adoption. we need toWe should prioritize use without arcanist. (See how GitHub does it)e addressing these pain points.
- Git branch mapped to differential revision might be a good move. See https://secure.phabricator.com/T5000 (using Differential with plain Git and not need Arcanist)
- This would likely mean having Phabricator knowing which branches to track and any branches being pushed which are untracked would be converted into a Differential Revision instead of public branch.
- Similarly for Mercurial this would likely mean translating their "topics" into Differential Revisions.
---
==Action items:
- @Matthew Create task and discussion around integrating Askimet.
- ~~@speck Create task about auto deployment to upstream. ~~
- @Matthew collect list of prototype and deprecated applications, make a task for each discussing what to do.
- @speck Investigate usefulness of using translations to help with rebrand process.
- @dcog Proof of concept to work around language issues.