In T15033#1512, @golyalpha wrote:

Yes, that's why I'm saying "yeah, great idea, let's do this, but let's also create a config toggle so that it can be disabled for people and orgs who don't need it".

In T15033#1516, @gadgetsteve wrote:

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

@dcog Just:

In T15033#1516, @gadgetsteve wrote:

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

I18n is also fairly important from the point of view that citizens in certain jurisdictions are basically legally immune against documents written in a language different from the official language of their jurisdiction, so, +1 on that.

Would it worth considering having multiple versions available with which is displayed determined by locale & language selection, (I18n & I10n). Then places with specific legislation could display the boilerplate or customised version and places without could, potentially, mention it with a link rather than having a specific sign-off and also linguistic problems could be addressed by the instance maintainer(s).

@Labricator Definitely - as potentially contributors can be from anywhere in the world, including places with GDPR or equivalent legislation. (Note that I am In Wales, UK so would be covered). I am reasonably sure, not a lawyer remember, the legislation is written in such a way that you can't get away with things like "the data is stored somewhere without DGPR so it doesn't apply", etc.

Yes, that's why I'm saying "yeah, great idea, let's do this, but let's also create a config toggle so that it can be disabled for people and orgs who don't need it".

What about the public versions? It still should have a GDPR notification.

Yes, the GDPR notice must inform about each and every purpose specifically. But it must do so only once - that can be at sign up.

The EU & UK GDPR provisions are very specific that each data gathering application must inform the user:

Definitely a good idea for anyone who wants to run Phorge in EU/UK or work with EU/UK contributors. Though it really is only necessary for the signup page - individual repositories really only have to worry about CLAs (if relevant).

Wouldn't this be a subtask of Legal? If admin has access to shell and/or PII, then this would be something for legal stuff.

I'd definitely recommend this change. Although I am not the best with legal mumbo jumbo, this would definitely be a must-have.

Great, thanks for the info.

@io for GitHub we have a task (T15046)

Hi all,

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

Also this Vagrant pattern should work first-run with vagrant up: https://we.phorge.it/T15027#852

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

Yes - I could have some availability - Normally evenings (US Central Time) -

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

@speck What can I help with here? - Are we waiting on upstream for anything currently?

The effort to rebrand Phabricator is going to result in changes to a lot of text which would likely invalidate a large number of translation entries.

At my company we have a similar situation however our management system is something we also actively develop. We solved this problem by configuring a web hook to hit an endpoint for the activities we are interested in having people track. The endpoint receives the transactions, pulls some additional info, and creates time-tracked activities for them in an aggregated list. Employees review the list and update time for each activity. It works pretty well and is not limited to activities from Phab allowing other systems to post activity to report, and for employees it’s nice because we can present the activity they’ve done and only require they estimate time spent as all other context is linked up.

and yes, I'm also running phabricator on top of CentOS 7 (using PHP 7.x via SCL).

In T15047#1302, @Ekubischta wrote:

Isn't Centos End of Life soon?

Is it possible to pick a branching off point?

Yep I think this makes sense and is why I think our first release should still support PHP 5.4 but we can move off it after that.

Is it possible to pick a branching off point?

Also, https://secure.phabricator.com/T7413 for the phone-home feature.

The kind of teams that use Centos/Redhat are very conservative - they're exactly the teams that would not install PHP from an "alternative" source (or from source code). They also tend to keep to older OS versions, as long as they are supported, and would not be happy with a single machine being different from the rest.
All that to say, it would make these teams sad to require an upgrade.

I'm mostly a Debian person (so I'm not aware of CentOS specifics) but my understanding is that CentOS 7 shipped with PHP 5.4 and has newer versions available via alternative repositories (not sure if official or not), while CentOS 8 (and Rocky Linux 8, if that matters) had PHP 7.2 by default and shipped a few years back. Is there a reason we're not basing our PHP support on latest distro releases (plus something like a year or two for a transition buffer), especially if newer PHP versions are available for older distro versions available as backports? I don't think requiring PHP / distro upgrades every few years is unreasonable.

Isn't Centos End of Life soon?

+1 for CentOS 7.

Agreed. We should aim to follow some specific conservative release. CentOS 7 seems reasonable.

We should include the Diviner and tech docs generation as part of the upgrade process of this server, that should ensure it's always up to date.

@MikeCripps welcome aboard! I added you to trusted contributors group.

I think our general strategy here should be focused around the versions of PHP available from the default/common package repositories for major server-based Linux distributions. There might be some situations where those package repositories only support very old versions (e.g. CentOS 7) which we should only plan to provide documentation for how to get the required version of PHP installed.

I will note that also the tech docs aren’t fully generated since there should be docs for most of the phorge/phabricator classes. Also the arcanist docs aren’t generated at all.

The Server also needs to periodically rebuild the Diviner Books to keep them in sync with Source Code. Eg. just set up a crontab entry. Or later, if more traffic is on the page: rebuild it once a commit affecting the Docs is committed.

Any chance that anyone has insight on D25015? Specifically, a way to get l18n (internationalization/translation) information from PHP into JavaScript from a minimalist approach

In T15010#1272, @MikeCripps wrote:

Really glad to see Phabricator will live on - I've previously managed some bugfixes in an external repo and would love to try to get them into upstream. I've run Phabricator instances for 7 of the last 9 years (and was unable to convince my previous employer to switch) so I've got a bit of experience on the managing side as well.

Really glad to see Phabricator will live on - I've previously managed some bugfixes in an external repo and would love to try to get them into upstream. I've run Phabricator instances for 7 of the last 9 years (and was unable to convince my previous employer to switch) so I've got a bit of experience on the managing side as well.

Automated Landing should be what adds the "Land Revision" button to revisions -- so not fully automated but allows someone to land without needing a local clone to manage.

Also when I look at a diff on upstream phabricator i see a land revision button - but I don’t see that for diffs on this instance.

@speck for rARC Trusted Contributors can land but rP is restricted to Blessed Committers

I'd suggest starting of the starmap by shedding some/most of the applications that were not part of the core of Phabricator or have been in the Prototype phase for a long time, allowing the project to regain focus and improve on the things that make Phorge unique. This would provide a number of advantages:

I added you both as well! Welcome to the team. If anyone has pre-existing functionality that they feel would be good to include in the upstream feel free to submit the changes. There's ongoing work (unfortunately slowly) to rebrand the project, but that's not holding up other changes at this time.

I'd be happy to contribute. I currently maintain an installation with over 4,000 git repos and over 2,000 users since 2016. Our company apparently had the highest karma count by a wide margin with our Phacility Support Pact, for whatever that's worth :)

I would also love to contribute to Phorge. I have signed the legalpad doc.

I added @dcog @codemouse92 and @mydeveloperday to the trusted contributors group. Glad to have everyone involved!

Not sure if this is where to mention, I would definitely like to help develop/maintain/review Phorge (I have signed the doc), I currently maintain a 600+ user Phabricator instance housing 50+ git repos,

In T15010#1062, @avivey wrote:

Any user should be able to sign the doc at L1 Phorge Vision Statement - did you try it and got an error?

In T15010#1060, @codemouse92 wrote:

I agree with the doc, and would like to sign too.

Glad to see Phabricator continuing as Phorge. Not going to lie, I had a panic attack this morning when I found out that Phacility was winding down.

I can help out with upstream merges. I've been doing it on a regular basis for Wikimedia for a long time now. It's rarely been a problem but I'm been careful to make sure that Wikimedia's fork doesn't drift too far away from upstream.

Handling of merging upstream changes will probably lead to some challenging merges done by people who did not author the original changes in Phorge. I don't know what the best way is to work around this. Maybe if we regularly (daily?) pull in changes from upstream, merge into our own master branch which everyone lands onto that should mostly catch merge issues?

There already are a bunch of worthwhile changes in Phabricator we should pick up; @Matthew - want to load them to check out the procedure? I can do that otherwise.

I would like to be a part of the core team, and I've signed the document.

In T15030#978, @20after4 wrote:

regarding a monorepo, I'm not sure if there is an advantage to that, I'm fine with individual repos. I currently maintain most of Wikimedia's extensions in a single monorepo but I'd consider splitting them out into individual repos if any one them were candidates for upstreaming.

regarding a monorepo, I'm not sure if there is an advantage to that, I'm fine with individual repos. I currently maintain most of Wikimedia's extensions in a single monorepo but I'd consider splitting them out into individual repos if any one them were candidates for upstreaming.

I'd like to host https://github.com/wikimedia/phabricator-antivandalism here, perhaps under a new name.

In T15030#972, @avivey wrote:

A space-zombie game that can report high-scores to IRC, Slack and Phorge.

Here's the terms I've been thinking of for accepting a project to Phactory:

1. Directly related to Phorge in a significant way:

Good: Module for integration with some other system; New Phorge app that does something reasonable; scripts for administration work.
Bad: A space-zombie game that can report high-scores to IRC, Slack and Phorge.

Checking the Wikipedia entry for GDPR at https://en.wikipedia.org/wiki/General_Data_Protection_Regulation it mentions that this regulation or other similar ones have been enacted in:

Of course since Phorge itself is a public project with, potentially, UK/EU contributors the signup/login page should really display such a warning.

In T15014#929, @avivey wrote:

nit-pick: maybe name them phabricator/master and phabricator/stable

In T15030#949, @0 wrote:

There are some projects listed on the Phabricator Community Resources page. Would all of those be eligible for hosting here, or would there be some criteria to limit the number of external projects?

If it's not worthwhile then let's not do it

There are some projects listed on the Phabricator Community Resources page. Would all of those be eligible for hosting here, or would there be some criteria to limit the number of external projects?

But why would we need to explicitly keep them? They already exist upstream...

My suspicion, though I hadn't thought through it much, is that it might be useful during migration periods where someone has the repository checked out and there's are clear linear branches of the phabricator development vs. phorge development.

FWIW I think the master / stable split happened upstream due to some planned deep rewrites. For our process I'd rather go masteronly and not have a separately stable or release branch.

nit-pick: maybe name them phabricator/master and phabricator/stable.

I'm fine with whatever naming

In T15030#916, @dcog wrote:

In T15030#914, @avivey wrote:

We are planning on hosting community-driven extensions/projects (temp codename "Phactory"), either here or in a different domain; the idea is to have each project maintain their own repositories.

That sounds awesome! Cool name :) Curious, did this come up in Zulip? I need to log back in there.

nit-pick: maybe name them phabricator/master and phabricator/stable.

(I should stop reading stuff before coffee. You'd think I'd know that by now...)