Set policy.allow-public to true in your config, which will allow you to use the "Public (No Login Required)" policy setting. You can do this from the Config application on your instance.

You can then set sections of the wiki to use this setting. Since Phriction policies are hierarchical, you'll probably want to make the root document public and have it point to the closed and open sections of the wiki, then have an open (public) section and a closed (nonpublic) section.

(The wiki on this install is configured similarly, although it's almost entirely public.)

Just simply allow public and remember that "To view a wiki document, you must also be able to view all of its parents." It works almost out of the box.

This does appear to resolve my immediate needs very nicely. I'll take a look at using this feature later today.

As an intensification of it, which is squarely in the "nice to have" category over the "needs", it'd be nice to have a semi-public section of the wiki as well for information which is too private to be completely publicly exposed but still should be viewed by a large number of people (e.g., perhaps, all actual customers).

This again tangles with the pay-per-user system of Phacility. It'd be another reason why I'd consider moving to a self-hosted version so I could offer more user log-ins.

Perhaps another way to solve this, however, would just be the ability to export subtrees. I'd be happy sending out static documentation to private users as well.

@tel, Can't you create some password-protected "guest" account(s) and give out the password(s) to your customers? I'm thinking that exports are too static and would need to be updated every time the wiki sub-tree changes...

That's a good point and a perfectly workable solution—good call.

We're potentially open to adding limited-access accounts but haven't seen much demand yet (so we aren't sure what they should look like) and there isn't a really a bright line between "limited access" and "full access" that we can identify offhand.

The most obvious one would be "read-only", but it seems reasonable that installs may want limited-access users who can, e.g., file bugs and add comments. We also don't really want to add a lot of product complexity to Phabricator just so we can slice up free vs paid accounts in a granular way in the Phacility cluster (e.g., they can comment but not close or review or push or something like that).

We could also do something simple like "email us and we'll flag the accounts as free", but that's kind of a lot of overhead and doesn't seem like it would scale very well in the long run, and just giving administrators a "don't bill me for this account" button feels too open to abuse.

If you have any other ideas on this, we'd be interested in your thoughts.

So, let me first walk out my use case a bit further.

I'm currently working on a project which involves a lot of collaboration. This includes heavily involved members from another company, technical contributors at my company, project relevant research contributors at both companies, and "project irrelevant" non-contributors at my company. A lot of noses.

It's important that some amount of documentation is visible to everyone. I'm often going to seek review from others, e.g., and I'd also like to be able to demonstrate work or tell people to follow a particular task to see a feature they're interested in head toward completion. In an open source mode this is all done and completely solved through just merely making the whole thing public or making it trivial to get your own log in. In the weird collaborative environment I'd be happy solving this using user permissions and can solve at least some small parts through making parts of the wiki public (as this tasks suggests).

It's worth noting that there's a limit to the amount of data I'd be willing to make public. Even now the page I've publicized is a little bit sensitive and I'd prefer other solutions to handle data just like it.

Phacility is great, but at $20/u/m I lose the user administration option and it becomes hard to share information.

Putting my product owner hat on, now...

The core value of Phabricator is intensely visible collaboration between people. Essentially, you create and capture the most value when two or more authors are submitting data to Phabricator and negotiating differences of opinion and implementation via it. If I were doing those tasks and Phabricator vanished I'd cry. It's absolutely worth $20/u/m for people acting at that level.

I'm aware of this, however, because I've used open source Phabricator installs so I've seen the whole process.

Here are some other user segments, however, which exist and could derive value from some use of Phabricator:

1. Customers of the product being developed through Phabricator
2. Managers of development tasks managed in Phabricator
3. Members of other teams on other projects which do not use Phabricator either because it's a poor fit for their work or they have other tools
4. Collaborators on a Phab managed project who need to track progress
5. Engaged, trusted customers who use Phab to create new tasks to be triaged by the team

Right now, $20/u/m fails to segment these customers and therefore fails to allow Phabricator to get as much use as possible. Some of them are a little solved: (5) is partially solved by inbound email based task creation, (1) is probably solvable via public wikis.

(2) and (3) are very interesting to you guys. If you put Phab in front of more non-users within a company which has already partially bought into using it then you'll be creating great new sales opportunities and incentivizing Phab deployments to grow. Again, this runs off the assumption that core value is generated when heavy contributors contribute via Phab, you wouldn't want to slow down the rate at which non-contributing managers use it nor the rate at which non-contributing potential-contributors use it.

Finally, (4) is straight value-add for some uses of Phabricator. Phab stores a lot of highly sensitive information and you want to share that selectively with some people. This is a low-use mode, however. These collaborators might come and go, might only ever look at one document once, etc, etc.

So, if I were you guys I'd at least do some research into what delimits a "core value creating user" of Phabricator—which you can almost certainly do by analyzing existing, public deployments—and then tighten Phacility charges down around it. Maybe $1/u/m for "basic users" and $20/u/m for users with write privileges in the core value creation segments.

A segmentation like that would allow many more people to derive contagious value from Phabricator and hopefully increase the value of using it while driving more sales. It might be nice to price segment a little more, even, to capture "heavy users", "heavy readers", and "light users" separately.

Anyway, those are my 2c spun out from considering Phacility in my use cases. It's definitely not something to dive into just because one customer brings it up, but it might be a research effort you could take a look into.

For my own use case, today, what I think I'll do is q's suggestion: generate a single "non-contributor" account and give everyone log in credentials to it. It's a security concern, but a manageable one since there are only so many people I'd be sharing it with and I can keep scrambling the password. Then, those who consistently need to be able to add value and need to have their identity tracked when they do so will be upgraded to pull, paying accounts.

I get the sense many similar products to Phabricator charge for license packs for this very reason. That is, they sell you accounts in packs of 10s or 20s, so if you had 21 people at your company, you'd have to pay for 30 seats. This means there will always be some slack in your seats and you're more incentivized to fill them up with less contributing users, because, why not? I'm not personally a fan of this model, so we're happy to explore other options. But as far as "light" and "heavy" mixtures go, I don't think we have any programmatic means of determining that, and I'm not aware of many SaaS products that do (looking at the nearest competition).

We're going to be more inclined to improve the footprint of Phabricator from a product perspective (ie, add more features and tools, like team chat) to make it more valuable for everyone.

Yeah, I agree that model is slimey. It's strict trick and sunk cost fallacy instead of progressive value increase. I think segmentation is fine when it leads to opening the ability for more people to receive value... Not when it just tricks people into buying more.

—
Sent from Mailbox

We have a product Nuance that we're kicking around (helpdesk) which would I think be a good value for Phacility. It would enable non-account people to file bugs and get support without a charged account. We haven't put much time into it, but I'd hope it'd at least solve the most common cases like "Sales wants to file bugs, and nothing else, why pay $20 a person for that?"

Yeah, totally. That sounds like it's in the same direction.

—
Sent from Mailbox