Skip to content
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

Closed
wants to merge 3 commits into from

Conversation

rgraber
Copy link
Contributor

@rgraber rgraber commented Mar 1, 2023

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

  • moving it to Best Practices
  • adding a section for the ADR that should be included
  • adding a change history

Note this will be kept as 2 separate commits for merge for cleaner history.

@rgraber rgraber force-pushed the rsgraber/20230301-move-oep-49 branch 2 times, most recently from 7a1a48f to 0e1bd18 Compare March 1, 2023 14:33
@rgraber rgraber marked this pull request as ready for review March 1, 2023 14:34
@rgraber rgraber force-pushed the rsgraber/20230301-move-oep-49 branch from b220e53 to 6dc6839 Compare March 1, 2023 14:36
Copy link
Contributor

@robrap robrap left a 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
Copy link
Contributor

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?

Suggested change
docs/decisions/0001-purpose-of-this-repo.rst or 0001-purpose-of-this-app.rst
docs/decisions/0001-purpose-of-this-app.rst

Copy link
Contributor Author

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?

Copy link
Member

@kdmccormick kdmccormick Mar 1, 2023

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@rgraber rgraber Mar 1, 2023

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.

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor Author

@rgraber rgraber Mar 1, 2023

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR has been updated

oeps/best-practices/oep-0049-django-app-patterns.rst Outdated Show resolved Hide resolved
@timmc-edx
Copy link
Contributor

Agreed with Robert's recommendations -- beyond those, looks good to go.

@rgraber rgraber force-pushed the rsgraber/20230301-move-oep-49 branch 3 times, most recently from 6a825b4 to 27a510b Compare March 1, 2023 17:24

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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.
  2. 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.

Copy link
Contributor Author

@rgraber rgraber Mar 1, 2023

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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.

Copy link
Member

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`_).
Copy link
Member

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?

Copy link
Contributor Author

@rgraber rgraber Mar 2, 2023

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

@kdmccormick kdmccormick left a 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`_
Copy link
Contributor

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.

@rgraber rgraber force-pushed the rsgraber/20230301-move-oep-49 branch from 4b44466 to 15d51a7 Compare March 2, 2023 20:03
docs: update oep-49 for clarity around new apps
@rgraber rgraber closed this Mar 3, 2023
@rgraber rgraber deleted the rsgraber/20230301-move-oep-49 branch March 3, 2023 13:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants