WIP collaboration document #2507
Conversation
|
Here is a screenshot I have saved to include in the doc.
|
dotNomad
force-pushed
the
dotnomad/collab-doc
branch
from
6d54a25 to
80c7f32
Compare
| ## Initial setup | ||
|
|
||
| To ensure that others can collaborate without issue the deployment and | ||
| configuration files should be available. |
There was a problem hiding this comment.
I'm not sure the reader will identify the deployment and configuration files with the same ones as we technically would. Should a background explanation or reference to the functionality of those files (and location) be included before asking that they be available?
There was a problem hiding this comment.
Definitely. With the way I work on documents like this I brain dump, trim, and repeat so the order ends up being a bit odd until it is refined. The explanation should be higher up.
|
|
||
| That means including them in the repository for the project or including them | ||
| in the `files` attribute in the configuration so they are available in the | ||
| content bundle. |
There was a problem hiding this comment.
With my earlier comment in mind, maybe start with a publisher creating a project that is not being collaborated on and then take the next steps to make sure it can be collaborated on, then switch to the collaborator's tasks?
There was a problem hiding this comment.
That is interesting. I don't want to repeat too much that is in the "Publishing from VS Code or Positron" document but I do like the idea of starting from the point of view of setting up a project for collaboration.
|
|
||
| Download the Source Version content bundle. If .posit files are included. | ||
|
|
||
| They are included by default |
There was a problem hiding this comment.
not sure about the period at the end of line 37 vs this next line of being included by default?
Were you trying to address the fact that if publisher is used to deploy the project, the .posit files are included by default?
That brings up another scenario we should address, when publisher was NOT used to deploy a project, what are the steps required to get collaboration to occur.
There was a problem hiding this comment.
This is just unstructured brain dumping on my part. The intention here was to note that if the content bundle doesn't include the .posit files I will need to write something.
when publisher was NOT used to deploy a project, what are the steps required to get collaboration to occur.
This is exactly what I mean to include in the final document. It will probably be a two part suggestion of:
- setup the
.positfiles by doing the initial setup above - re-publish
It will take some refining to avoid repeating too much information. I'm not sure if the "As a collaborator" and "Initial Setup" sections are the most helpful yet.
| Posit Publisher makes this easy by prompting you to _Create a new Credential_ | ||
| when the selected deployment requires a credential you don't have. | ||
|
|
||
| TODO: SCREENSHOT |
There was a problem hiding this comment.
ok, now I see this is a work in progress, as you've got the screenshot saved...
Sorry for the initial comments if it is not yet ready.
| content bundle from the latest Source Version on Posit Conect. | ||
|
|
||
| Doing so ensures that you have the most up-to-date content, but also | ||
| configuration settings and deployment details. |
There was a problem hiding this comment.
We should also consider some of the impacts that the different content types have on collaboration, such as the interpreter versions and if dependencies are being updated.
This should include a special clarification for R environments, where for now, collaborators need to agree upon runtime versions and maintain the appropriate package installations.
It's less of an issue for Python and Quarto, so I think we can skim over the details for them, while still wanting to promote best practices of using the same versions while collaborating.
There was a problem hiding this comment.
Definitely. I think a note about how package files, and versions in the configuration would be good to include.
| Collaborate easily with your team by sharing your configurations and | ||
| deployments. Others can pick up where you left off and | ||
|
|
||
| Allow collaborators to easily pick up where you left off by using the `.posit` |
There was a problem hiding this comment.
Should we switch this to call out the .posit/publisher files rather than just the .posit files?
There was a problem hiding this comment.
Yes that is a great point. I'll get that updated.
dotNomad
force-pushed
the
dotnomad/collab-doc
branch
from
80c7f32 to
428fbd0
Compare
This is a VERY MUCH WIP document describing the collaboration flow we envision for Publisher.
It isn't clear if this document will actually live in the repo, or in the Posit Connect docs. This is put up here to be potentially picked up while I'm on vacation.
Tackles #2383