Skip to content

Conversation

@caydnn
Copy link
Contributor

@caydnn caydnn commented Oct 8, 2025

Adds the end of semester blog post for semester 2 of the 2025 Curtin Capstone collaboration with BeeWare.
The post will highlight the teams contributions from the second half of the year-long internship.

PR Checklist:

  • [ x ] All new features have been tested
  • [ x ] All new features have been documented
  • [ x ] I have read the CONTRIBUTING.md file
  • [ x ] I will abide by the code of conduct

@caydnn caydnn marked this pull request as ready for review October 23, 2025 04:58
@caydnn
Copy link
Contributor Author

caydnn commented Oct 23, 2025

Hi @freakboy3742, we've added all our parts to the blog post. Feel free to check it out when you get a chance 😄

Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

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

Looks good team! I've lefts some review notes inline. Most of them relate to either rendering issues, or the sort of "narrative voice" we use in blog posts. If you need any clarification on any of these points, just ask.

If I've made a point in one section (e.g., about spaces between paragraphs), that note will generally apply to every other section as well (where appropriate), so just because I didn't specifically comment on your section of the document, doesn't mean you're in the clear :-)

- Mitchell Pontague ([mEp3ii2](https://github.com/mEp3ii2)); Software Engineering
- Veronica Taniputra ([vt37](https://github.com/vt37)); Cyber Security

In the first semester, our team gained exposure to the BeeWare ecosystem through tackling a variety of small bug fixes within Briefcase and Toga, creating widgets for the web backend in Toga and completing small research tasks into the mechanisms within the BeeWare tools. After this, the team split off into pairs to plan out larger deliverable contributions that would add or changes features within BeeWare.
Copy link
Member

Choose a reason for hiding this comment

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

You could add a link to the first semester blog post here.


### Mitchell:

One of the most valuable lessons from BeeWare came while implementing a virtual environment context manager for Briefcase. During the planning and initial development, I was too focused on how this would work for the web development platform rather than on the actual design of the tool itself. My supervisor pointed out that this PR had applications in other areas within Briefcase and should be designed with those considerations in mind. I had been thinking in terms of "what does the web platform need?" when I should have been asking "what capability does the system need?" This misunderstanding affected my initial timeline and resulted in a much longer development cycle than intended, but it taught me something far more valuable. The real insight was that development shouldn't be task-specific but tool-specific. When working on something, it's not about what works for today's problem but what tool you're building that will work for any problem that emerges tomorrow. Good design means separating mechanism from policy: your tool provides the *how*, and each caller decides the *where*, *when*, and *why*. The goal isn't to predict every use case but to build tools that others can use as-is, without modification. When someone needs virtual environment management six months from now in a completely different context, they shouldn't have to change your code—they should just be able to call it with their parameters and move on. Build it once so it works everywhere, not once per use case. Ultimately, the best code is the code that works today but rather the code that's still working unchanged a year from now.
Copy link
Member

Choose a reason for hiding this comment

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

Great content; but could be broken into a couple of paragraphs (as with Kavi - make sure there's a blank line between paragraphs)

Copy link
Contributor

Choose a reason for hiding this comment

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

Updated


### Caydn:

- This year has taught me how to work effectively within both a small team and a large open-source project. It's been very eye opening navigating the expectations and workflows that come with contributing to a community-driven codebase.
Copy link
Member

Choose a reason for hiding this comment

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

As with Jaeden - this should be paragraphs not bullet points.

## Future work

- In Toga, `web/src/toga_web/static/toga.css` will need to be converted to an insert.
- Eg: `web/src/toga_web/deploy/inserts/briefcase.css~css`
Copy link
Member

Choose a reason for hiding this comment

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

There's two options here:

  1. An introductory paragraph with a tight list of bullet points; or
  2. A couple of paragraphs describing in high level terms with links to relevant outstanding PRs/designs.

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've added an opening paragraph at line 98. Did you need me to expand on it? :)

Copy link
Member

Choose a reason for hiding this comment

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

So - that introductory paragraph is kind of half way to what I intended.

My main issue is that the bullet point list is inconsistent with the rest of the text. After a lot of narrative descriptions, we've got a set of bullet points reads a bit like a first draft for the paragraphs that should be here. If the future work was as simple as "here are the four issues that need to be resolved" or "here are the 3 PRs that need to be completed", then a bullet list might be appropriate. Here we have a combination of short descriptions and links; some of which is duplicating content that are covered in more detail in the handover reports.

Rather than duplicate the handover reports, this further work section should be giving a really high level summary of the work to be done, and then referring to those handover reports for more details.

(Also some of the todo items have already been done :-) )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alrighty that makes sense, I'll see if I can get the team to update their sections for this. A few of us have exams tomorrow but we should be able to change this soon.

For the Insertion system changes, would you like a similar approach but with a link to the remaining issue ticket instead of a handover report?

Copy link
Member

Choose a reason for hiding this comment

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

Alrighty that makes sense, I'll see if I can get the team to update their sections for this. A few of us have exams tomorrow but we should be able to change this soon.

No problems - your exams should absolutely take priority. If we can get this wrapped up by the end of the week, that would be ideal.

For the Insertion system changes, would you like a similar approach but with a link to the remaining issue ticket instead of a handover report?

I'm not sure I follow you're referring to here. My original comment was intended as highlighting an issue with the entire "future work" section, not a flag on this specific bullet point. If there's a handover report, link to it, with maybe a very brief summary of the nature of the outstanding work; if the future work is just a ticket or two, link to those.

To avoid content duplication, it might also be appropriate to remove references to the handover reports in the sections above, and consolidate them down in this future work section.

@caydnn
Copy link
Contributor Author

caydnn commented Oct 26, 2025

Hi @freakboy3742, we have addressed your comments and believe this is ready to go.
Feel free to check it out again :)

Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

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

Body content all looks good (with a couple of minor suggestions inline).

The only thing outstanding is the outstanding note on the last section.

@caydnn
Copy link
Contributor Author

caydnn commented Oct 31, 2025

Hi @freakboy3742
Apologies for the delay, the future work section has been updated now :)

@freakboy3742 freakboy3742 added the preview Approved for an automated preview label Nov 4, 2025
@github-actions
Copy link

github-actions bot commented Nov 4, 2025

Visit the preview URL for this PR (updated for commit 1aae529):

https://beeware-org--pr705-lektor-lgzwbvz0.web.app

(expires Tue, 11 Nov 2025 00:12:25 GMT)

🔥 via Firebase Hosting GitHub Action 🌎

Sign: b0da44bc067e7d9a4255c77cb2c5fce572218cec

@freakboy3742 freakboy3742 merged commit db15d1d into beeware:lektor Nov 4, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

preview Approved for an automated preview

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants