-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: update oep-49 for clarity around new apps #455
Conversation
7a1a48f
to
0e1bd18
Compare
b220e53
to
6dc6839
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Also, I didn't see you post this review in the community channels. Were you planning to do that after you have internal approval?
@@ -267,7 +267,31 @@ Do note that even if you expose your tasks through ``api.py`` to be used by othe | |||
still be configured with the ``tasks`` import name, as the celery identifier for your task (as set by the celery | |||
decorator) is based off the original file. | |||
|
|||
docs/decisions/0001-purpose-of-this-repo.rst or 0001-purpose-of-this-app.rst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why repo? This is all about the app, right?
docs/decisions/0001-purpose-of-this-repo.rst or 0001-purpose-of-this-app.rst | |
docs/decisions/0001-purpose-of-this-app.rst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually that's an interesting point. If a new repo has only one new app, do we want both a purpose of this app and a purpose of this repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My gut reaction is that requring separate ADRs for the new repo and the initial apps sounds like too much paperwork. However, requiring ADRs for apps created in exisitings repo does sound fair to me.
As a conpromise, we could recommend that the initial app(s) have stub ADRs, each of which point to the repo-level ADR. The repo cookiecutter could be updated to provide that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd lost track of this being for apps in general, which might be in their own repos. If it's a single-app repo, I think there should just be one docs/ dir, either at the repo root or inside the app. Top-level sounds more convenient and easy to notice. The one reason I can think of to put it inside the app is in case the code moves into another repo (maybe absorbed into an IDA?), since having it at the repo root might risk it being lost. But I don't know how plausible that is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @kdmccormick 's suggestion of the stub ADR pointing to the main ADR addresses most of your concerns @timmc-edx . The documentation is effectively centralized, but if someone moves the app folder they should notice that something is up when their link breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A stub makes to me as well, yeah.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what it's worth, I wrote that proposal thinking about apps in an IDA, not single-app packages.
I would agree with @timmc-edx's earlier point that a single ADR in the root dir of the a single-app package is probably good enough. But if that's not that the consensus that's been reached here, that's fine with me too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated with the stub-ADR-in-the-app version. Even I find the phrasing I used confusing so if anyone has ideas for ways to express this more clearly I'm very much open to them.
I will squash the commits before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[inform] The updated text is in https://github.com/openedx/open-edx-proposals/pull/455/files#r1122281928, but the PR hasn't been updated yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR has been updated
Agreed with Robert's recommendations -- beyond those, looks good to go. |
6a825b4
to
27a510b
Compare
|
||
This should be an architectural decision record (ADR) describing the decision behind adding the app. Future ADRs should also be placed in this directory. See more about what should go in ADRs in the `ADRs section of OEP-0019`_ | ||
|
||
If this is a repository that only contains a single app, the information should be in a file called `0001-purpose-of-this-repo.rst`. There should be a `0001-purpose-of-this-app.rst` ADR in application subdirectory (in its own docs/decisions subdirectory) that just points to the repository-level one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I stick with my original proposal to update the title of this section to
docs/decisions/0001-purpose-of-this-app.rst
. All of the other sections are relative to the app directory. - I'm wondering if this could be simpler, and not necessarily require (0001-purpose-of-this-repo.rst), since this OEP isn't about that. How do you feel about something like the following?
If this is the only app in the entire repo, this ADR could refer to a ``0001-purpose-of-this-repo.rst`` in the repository-level docs/decisions directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would replace "could" with "should" but that's fine by me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rgraber: optional: You could reference https://github.com/openedx/edx-cookiecutters#3-todos-after-running-cookiecutter if you'd like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve once this has been updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend "[could/should] be a stub that links to" over "should refer to". I think the latter leaves room for misintepretation (ie "do I have to write a whole new ADR, that happens to contain a link to the repo ADR?")
|
||
This should be an architectural decision record (ADR) describing the decision behind adding the app. Future ADRs should also be placed in this directory. See more about what should go in ADRs in the `ADRs section of OEP-0019`_ | ||
|
||
If this is the only app in the repository, this ADR should just be a stub linking to the full ADR in `0001-purpose-of-this-repo.rst` (see `TODOs after running cookiecutter`_). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than adding this to the post-cookiecutter TODO list, could we add it to the cookiecutters as a part of this OEP change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in postpone this PR until we have updated the cookiecutter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, or at least until we have a draft PR ready to go for updating the cookiecutter. Since we are asking folks to make these additional ADRs starting now, my intuition is that it'd be best to provide the cookiecutter scaffolding now as well.
I don't know, maybe I'm underestimating the effort it'd take to update the cookiecutter. Don't take this as a blocking suggestion; what you have here is OK with me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm nervous about blocking this, so I'll leave this as is and then make an issue to add this to the cookiecutter if there isn't one already. If there is one I'll add a task to update this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the benefit of blocking on this. The OEP states what someone should do. Cookiecutter changes may help automate some of that, but I bet there are a ton of automation improvements in our OEPs, and this is just one.
Also, one could argue that adding the stub automatically will make it less likely that anyone will update it in the many cases where it should be updated. An alternative would be to add a codeblock here with an example link, if someone works out the rST reference that would work. Note, this too could come later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now openedx/edx-cookiecutters#299. We can further discuss there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a suggestion in this thread, but it's not blocking. Thanks for the update!
docs/decisions/0001-purpose-of-this-app.rst | ||
=========================================== | ||
|
||
This should be an architectural decision record (ADR) describing the decision behind adding the app. Future ADRs should also be placed in this directory. See more about what should go in ADRs in the `ADRs section of OEP-0019`_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Missing period at the end.
4b44466
to
15d51a7
Compare
docs: update oep-49 for clarity around new apps
For anyone looking at this in the future:
Even though this PR says "Closed", it was in fact Merged.
Issue: openedx/edx-platform#31659
Update OEP-49 by
Note this will be kept as 2 separate commits for merge for cleaner history.