From 630cc19163907e26e6250c3b556f430f890b0669 Mon Sep 17 00:00:00 2001 From: Loymdayddaud <145969603+TheGiraffe3@users.noreply.github.com> Date: Fri, 6 Dec 2024 19:27:06 +0300 Subject: [PATCH] Fix many typos --- .../past/2022/importing-data-into-existing-tables.md | 2 +- docs/community/gsoc/past/2023/list-datatype.md | 6 +++--- .../gsoc/project-ideas/automatic-hint-reflection.md | 4 ++-- .../project-ideas/visualization-of-grouped-data.md | 4 ++-- docs/engineering/markdown.md | 5 ++--- docs/engineering/research/formulas.md | 4 ++-- docs/engineering/specs/internationalization.md | 2 +- docs/engineering/specs/worksheets-technical-specs.md | 2 +- docs/jobs/past/2021-04-designer.md | 2 +- docs/jobs/past/2021-04-frontend.md | 2 +- docs/jobs/past/2021-09-frontend.md | 2 +- .../specs/2022-01-views/03-the-query-builder.md | 4 ++-- docs/team/meeting-notes/2021/05/2021-05.md | 4 ++-- docs/team/meeting-notes/2021/09/2021-09.md | 4 ++-- docs/team/meeting-notes/2022/02/2022-02.md | 4 ++-- docs/team/meeting-notes/2022/03/2022-03.md | 4 ++-- docs/team/meeting-notes/2022/09/2022-09.md | 4 ++-- .../2024/01/2024-01-22-release-check-in.md | 4 ++-- .../meeting-notes/2024/01/2024-01-29-staff-meeting.md | 4 ++-- .../meeting-notes/2024/01/2024-01-31-staff-meeting.md | 2 +- .../2024/02/2024-02-12-beta-planning-meeting.md | 6 +++--- .../meeting-notes/2024/03/2024-03-06-staff-meeting.md | 4 ++-- .../2024/05/2024-05-30-maintainer-meeting.md | 4 ++-- .../2024/07/2024-07-16-maintainer-meeting.md | 2 +- .../2024/07/2024-07-23-maintainer-meeting.md | 2 +- .../2024/07/2024-07-24-permissions-retrospective.md | 6 +++--- docs/team/worklogs/archive/2023-07/anish.md | 6 +++--- docs/team/worklogs/archive/2023-07/pavish.md | 2 +- docs/team/worklogs/archive/2023-08/brent.md | 2 +- docs/team/worklogs/archive/2023-08/ghislaine.md | 2 +- docs/team/worklogs/archive/2023-08/pavish.md | 6 +++--- docs/team/worklogs/archive/2023-09/anish.md | 8 ++++---- docs/team/worklogs/archive/2023-09/pavish.md | 6 +++--- docs/team/worklogs/archive/2023-10/kriti.md | 2 +- docs/team/worklogs/archive/2023-10/pavish.md | 2 +- docs/team/worklogs/archive/dom.md | 2 +- docs/team/worklogs/archive/mukesh.md | 10 +++++----- docs/team/worklogs/archive/rajat.md | 4 ++-- docs/team/worklogs/sean.md | 6 +++--- 39 files changed, 75 insertions(+), 76 deletions(-) diff --git a/docs/community/gsoc/past/2022/importing-data-into-existing-tables.md b/docs/community/gsoc/past/2022/importing-data-into-existing-tables.md index 8332fcb8f..2166e3783 100644 --- a/docs/community/gsoc/past/2022/importing-data-into-existing-tables.md +++ b/docs/community/gsoc/past/2022/importing-data-into-existing-tables.md @@ -22,7 +22,7 @@ My project during the Google Summer of Code was to enhance the capability of Mat - Implementation and tests for column mapper: https://github.com/mathesar-foundation/mathesar/pull/1506 - Constraint violation handling during import: https://github.com/mathesar-foundation/mathesar/pull/1548 -- Implemetation and tests for suggesting column mappings: https://github.com/mathesar-foundation/mathesar/pull/1698 +- Implementation and tests for suggesting column mappings: https://github.com/mathesar-foundation/mathesar/pull/1698 ## Additional context diff --git a/docs/community/gsoc/past/2023/list-datatype.md b/docs/community/gsoc/past/2023/list-datatype.md index 9ccdba6d5..452a4fb0b 100644 --- a/docs/community/gsoc/past/2023/list-datatype.md +++ b/docs/community/gsoc/past/2023/list-datatype.md @@ -64,15 +64,15 @@ Also while trying to integrate this class to the project, I faced difficulties s The difficulty of introducing this decorator in the codebase and the type of changes required are indicative of the type of problems that could be found porting other pseudo data types. #### Custom adapter -It would give us more control if we develop a module that works directly with psycopg2, where we could fully handle the postgres-python (and viceversa) mapping of arrays. This module will also (probably) help us fix format issues when aggregating records of date like data types. See issues [#2962](https://github.com/mathesar-foundation/mathesar/issues/2962), [#2966](https://github.com/mathesar-foundation/mathesar/issues/2966). Custom adapters for date-related data types are discussed in the psycopg2 documentation, as some exact mappings are not possible [3]. +It would give us more control if we develop a module that works directly with psycopg2, where we could fully handle the postgres-python (and vice-versa) mapping of arrays. This module will also (probably) help us fix format issues when aggregating records of date like data types. See issues [#2962](https://github.com/mathesar-foundation/mathesar/issues/2962), [#2966](https://github.com/mathesar-foundation/mathesar/issues/2966). Custom adapters for date-related data types are discussed in the psycopg2 documentation, as some exact mappings are not possible [3]. This option will however, require more time both for planning and implementation, as this would be a new way of implementing a data type in Mathesar, possibly requiring modifications in several parts of the backend code; e.g. integration in the codebase will be more complex. Moreover, it works mostly on Pythonโ€™s side, meaning we are not enforcing anything on the DB side. ### Supporting n-dimensional arrays -Given that none of the ideas we had to attempt restricting arrays to 1 dimension were sucessful, we now move to consider supporting multidimensional ones. +Given that none of the ideas we had to attempt restricting arrays to 1 dimension were successful, we now move to consider supporting multidimensional ones. **Filters** -As reviewed earlier, opearations over n-dimensional arrays become confusing. +As reviewed earlier, operations over n-dimensional arrays become confusing. - Length: it needs to know over what dimension to count. ``` diff --git a/docs/community/gsoc/project-ideas/automatic-hint-reflection.md b/docs/community/gsoc/project-ideas/automatic-hint-reflection.md index 01ea8d3da..065199a03 100644 --- a/docs/community/gsoc/project-ideas/automatic-hint-reflection.md +++ b/docs/community/gsoc/project-ideas/automatic-hint-reflection.md @@ -62,7 +62,7 @@ The automatic reflection is not essential, but it could be a significant quality - Figure out when to reflect and how to cache the reflections so as to minimally burden the wider system with more state; - Do the implementation. -I would expect the above tasks to be performed (at least somewhat) asynchroniously. +I would expect the above tasks to be performed (at least somewhat) asynchronously. ## Expected Outcome An automatic PostgreSQL function (and possibly type) property reflection mechanism tailored to automatically finding useful hints for the hint system. @@ -82,4 +82,4 @@ I'd say a good candidate would be one that is comfortable taking the time to exp - **Primary Mentor**: Dominykas Mostauskis - **Backup Mentor**: Brent Moran -See our [Team Members](/team/members) page for Matrix and GitHub handles of mentors. \ No newline at end of file +See our [Team Members](/team/members) page for Matrix and GitHub handles of mentors. diff --git a/docs/community/gsoc/project-ideas/visualization-of-grouped-data.md b/docs/community/gsoc/project-ideas/visualization-of-grouped-data.md index e6bc4b41e..89e494986 100644 --- a/docs/community/gsoc/project-ideas/visualization-of-grouped-data.md +++ b/docs/community/gsoc/project-ideas/visualization-of-grouped-data.md @@ -18,7 +18,7 @@ An additional option to visualize the grouped results in the form of graphs or a - Research and come up UX design specs and wireframes for grouped data visualization. - Create necessary issues based on the finalized specs after review. - Research graphing libraries and identify the one most suitable with Mathesar's architecture and goals. -- Identify missing APIs or changes required in exising APIs and implement the necessary changes on the backend. +- Identify missing APIs or changes required in existing APIs and implement the necessary changes on the backend. - Implement the frontend data visualization interface. ## Expected Outcome @@ -31,4 +31,4 @@ A good candidate would be someone who is able to empathize and think from the pe - **Primary Mentor**: Pavish Kumar Ramani Gopal - **Backup Mentor**: Sean Colsen -See our [Team Members](/team/members) page for Matrix and GitHub handles of mentors. \ No newline at end of file +See our [Team Members](/team/members) page for Matrix and GitHub handles of mentors. diff --git a/docs/engineering/markdown.md b/docs/engineering/markdown.md index 01fc01a99..372227e3f 100644 --- a/docs/engineering/markdown.md +++ b/docs/engineering/markdown.md @@ -7,7 +7,7 @@ This page recommends guidelines to follow when writing Markdown in order to keep - Use **four spaces** for all indentation. !!! question "Rationale: ๐Ÿ’ผ Portability" - Most Markdown rendering platforms handle other indentation styles with some degree of consistency for _simple_ content, so at first this guideline may appear to be unecessary. But as content gets more complex, various edge cases tend to crop up which lead to inconsistencies. Maintaining four-space indentation across the board is the best way to ensure your indentation is **always** consistent. + Most Markdown rendering platforms handle other indentation styles with some degree of consistency for _simple_ content, so at first this guideline may appear to be unnecessary. But as content gets more complex, various edge cases tend to crop up which lead to inconsistencies. Maintaining four-space indentation across the board is the best way to ensure your indentation is **always** consistent. For example, when some list items are intended by only _two_ spaces: @@ -151,5 +151,4 @@ When a Markdown page links to another Markdown page, follow these patterns: Lorem ipsum dolor sit amet... ``` - Giving custom names to your heading anchors is nice because it allows us to change the heading text without breaking the crossreference. Plus it allows for shorter URLs. - + Giving custom names to your heading anchors is nice because it allows us to change the heading text without breaking the cross-reference. In addition, it allows for shorter URLs. diff --git a/docs/engineering/research/formulas.md b/docs/engineering/research/formulas.md index e6768008a..f117eb640 100644 --- a/docs/engineering/research/formulas.md +++ b/docs/engineering/research/formulas.md @@ -144,7 +144,7 @@ This is a report which details some research that Sean did in 2023-06 to vet the - โš–๏ธ **Deleting a referenced column** - - It's _possible_ to delete a referenced colum, but the resulting behavior may catch users off guard + - It's _possible_ to delete a referenced column, but the resulting behavior may catch users off guard ```sql alter table formulas drop column a; @@ -204,7 +204,7 @@ This is a report which details some research that Sean did in 2023-06 to vet the - Formula columns are _virtual_, not _stored_. That is, they are computed on the fly when the table results are displayed. - - Formulas are implemented at the _application layer_, not the _database layer_. This means the formula definition is stored in application-specific metatdata, and the formula column is not visible within the underlying database. If I update a referenced value outside NocoDB, then the result of the formula that NocoDB displays _will_ update, but only due to the virtual nature of the formula. The source data is read/write accessible outside NocoDB, but not the computed data. + - Formulas are implemented at the _application layer_, not the _database layer_. This means the formula definition is stored in application-specific metadata, and the formula column is not visible within the underlying database. If I update a referenced value outside NocoDB, then the result of the formula that NocoDB displays _will_ update, but only due to the virtual nature of the formula. The source data is read/write accessible outside NocoDB, but not the computed data. - NocoDB has its own special formula syntax and functions. diff --git a/docs/engineering/specs/internationalization.md b/docs/engineering/specs/internationalization.md index 790a1272c..0b13bc715 100644 --- a/docs/engineering/specs/internationalization.md +++ b/docs/engineering/specs/internationalization.md @@ -38,7 +38,7 @@ The bundle footprint of the suggested library is [low](https://github.com/ivanho Translations files will be loaded in parallel with the FE code. There are two approaches to it: 1. Detecting the language and adding the translations for that language in the common_data. But this will lead increase in the size of the common_data since the translations will grow with time. -2. Loading the translations via a script tag. This will require having a global loader in the index.html which get's hidden once the translations are loaded. +2. Loading the translations via a script tag. This will require having a global loader in the index.html which gets hidden once the translations are loaded. The final approach will be decided during the implementation and the tech spec will be updated accordingly. diff --git a/docs/engineering/specs/worksheets-technical-specs.md b/docs/engineering/specs/worksheets-technical-specs.md index 49e494ca1..a5d8a8aa5 100644 --- a/docs/engineering/specs/worksheets-technical-specs.md +++ b/docs/engineering/specs/worksheets-technical-specs.md @@ -132,7 +132,7 @@ TODO > > Before worksheets, Mathesar associated record summaries with each _table_ so that all FKs which referenced the same table would automatically use the same record summary. With worksheets, it is not (yet?) possible to configure a default per-table record summary template to always be used for references to that table. This behavior simplifies some things, but also has the following consequences: > - > - In some cases, there might be some more tedium associated with creating new worksheets because you can't easily re-use a record summary template that you created elsewhere. + > - In some cases, there might be some more tedium associated with creating new worksheets because you can't easily reuse a record summary template that you created elsewhere. > - The Record Page can't show a record summary for the record. > > I think these are acceptable tradeoffs though. The benefit of the worksheet approach is that different worksheets can have different record summary templates to refer to the same table. diff --git a/docs/jobs/past/2021-04-designer.md b/docs/jobs/past/2021-04-designer.md index 8a61e4f71..c71cd4a9b 100644 --- a/docs/jobs/past/2021-04-designer.md +++ b/docs/jobs/past/2021-04-designer.md @@ -17,7 +17,7 @@ We are a fully distributed team, and you can be located anywhere in the world, a ## Qualifications We're looking for a designer that has extensive experience with translating complex concepts into intuitive web interfaces for non-technical users and working with engineering teams to ship them. You should be an expert in design best practices, especially in accessibility and mobile-friendliness. You should also have experience conducting effective user interviews and usability testing, and generally be an advocate for creating an exceptional user experience. -Excellent communication skills in English (both written and verbal) are essential, since this position is fully remote. You should be able to work indpendently, build good working relationships remotely, and be a proactive communicator. You should also enjoy writing documentation, helping others, and building a community. You're probably also curious and enjoy learning new things. +Excellent communication skills in English (both written and verbal) are essential, since this position is fully remote. You should be able to work independently, build good working relationships remotely, and be a proactive communicator. You should also enjoy writing documentation, helping others, and building a community. You're probably also curious and enjoy learning new things. Some nice-to-haves: diff --git a/docs/jobs/past/2021-04-frontend.md b/docs/jobs/past/2021-04-frontend.md index f8f6ee5f6..8c311677a 100644 --- a/docs/jobs/past/2021-04-frontend.md +++ b/docs/jobs/past/2021-04-frontend.md @@ -17,7 +17,7 @@ We are a fully distributed team, and you can be located anywhere in the world, a ## Qualifications We're looking for an experienced engineer that has architected, built, and deployed complex frontend applications that deal with large amounts of data. Ensuring scalability, accessibility, and performance are critical, and ideally, you have strong opinions on how to make that happen. We also expect you to be an advocate for creating an exceptional user experience. -Excellent communication skills in English (both written and verbal) are essential, since this position is fully remote. You should be able to work indpendently, build good working relationships remotely, and be a proactive communicator. You should also enjoy writing documentation, helping others, and building a community. You're probably also curious and enjoy learning new things. +Excellent communication skills in English (both written and verbal) are essential, since this position is fully remote. You should be able to work independently, build good working relationships remotely, and be a proactive communicator. You should also enjoy writing documentation, helping others, and building a community. You're probably also curious and enjoy learning new things. Some nice-to-haves: diff --git a/docs/jobs/past/2021-09-frontend.md b/docs/jobs/past/2021-09-frontend.md index 78d0e592d..f851fbba7 100644 --- a/docs/jobs/past/2021-09-frontend.md +++ b/docs/jobs/past/2021-09-frontend.md @@ -21,7 +21,7 @@ We expect you to: - have experience working professionally within an engineering team. - have excellent verbal communication skills in English. - enjoy explaining your ideas quickly, clearly, and comprehensively in writing. -- work indpendently, build good working relationships remotely, and communicate proactively. +- work independently, build good working relationships remotely, and communicate proactively. - be an advocate for an exceptional user experience. - be interested in building an open source community and helping others contribute to the project. - be curious and enjoy learning new things. diff --git a/docs/product/specs/2022-01-views/03-the-query-builder.md b/docs/product/specs/2022-01-views/03-the-query-builder.md index bfc4048ef..249ddb16d 100644 --- a/docs/product/specs/2022-01-views/03-the-query-builder.md +++ b/docs/product/specs/2022-01-views/03-the-query-builder.md @@ -53,10 +53,10 @@ Here's a flowchart of decisions that need to be made when adding columns. This i In addition to selecting output columns, the user should be able to add to the query in the following ways. ### Filtering -The user can add filters to filter down the results of the query to a subset of rows. They can use any of the query's ouput columns in filters. The filters available for the column will depend its data type and will offer a similar experience to table or view filters. +The user can add filters to filter down the results of the query to a subset of rows. They can use any of the query's output columns in filters. The filters available for the column will depend its data type and will offer a similar experience to table or view filters. ### Sorting -The user can sort the query results by one or more of the query's ouput columns. Query sorting should provide a similar experience to table or view sorting. +The user can sort the query results by one or more of the query's output columns. Query sorting should provide a similar experience to table or view sorting. ### Summarization The user should be able to summarize the query by one of the query's output columns. This involves the following steps: diff --git a/docs/team/meeting-notes/2021/05/2021-05.md b/docs/team/meeting-notes/2021/05/2021-05.md index 3cd231780..945d6dbef 100644 --- a/docs/team/meeting-notes/2021/05/2021-05.md +++ b/docs/team/meeting-notes/2021/05/2021-05.md @@ -127,7 +127,7 @@ Next week - on call, may have to drop out during meeting. - Meetings so far are frequent, we are relying too much on synchronous discussion - Async discussions are better, we can think about things more, and it's documented - Design reviews - it's still useful to have those synchronously -- We can schedule additional synchonous meetings as needed ad-hoc +- We can schedule additional synchronous meetings as needed ad-hoc - Only Tuesdays starting next week - Will also give us more uninterrupted time - Team events after Pavish starts full time for team building @@ -852,7 +852,7 @@ Ghislaine will match CSS class names to Figma components. ### This week's plan #### Pavish -- Implement routing on client (take over from server after intial page load) +- Implement routing on client (take over from server after initial page load) - Table view using Svelte #### Ghislaine diff --git a/docs/team/meeting-notes/2021/09/2021-09.md b/docs/team/meeting-notes/2021/09/2021-09.md index 2a7fc77b4..9e20efe07 100644 --- a/docs/team/meeting-notes/2021/09/2021-09.md +++ b/docs/team/meeting-notes/2021/09/2021-09.md @@ -32,7 +32,7 @@ Current process: Kriti making tickets - Lots of tickets, huge volume - Can't hash out the details ahead of time - - e.g. money type ticket had potentially forseeable issues, but only with serious time investment + - e.g. money type ticket had potentially foreseeable issues, but only with serious time investment - Missing details - Interdependencies - Not enough frontend tickets @@ -57,7 +57,7 @@ Current process: Kriti making tickets - Some decisions need to be made with that in mind. - Two stage process: - Test with users and make improvements before release - - Continue to make imporvements after release. + - Continue to make improvements after release. - Once we have all the pieces implemented, we can think through user scenarios and we'll be thinking about things as a "user flow" rather than a feature. - e.g. user may not "create a view", they'll end up with a view - The good thing is that we're not doing anything too abstract right now, we do need to consider user flow when creating abstract things. diff --git a/docs/team/meeting-notes/2022/02/2022-02.md b/docs/team/meeting-notes/2022/02/2022-02.md index e053e19dc..68b33d7b0 100644 --- a/docs/team/meeting-notes/2022/02/2022-02.md +++ b/docs/team/meeting-notes/2022/02/2022-02.md @@ -262,7 +262,7 @@ Sean will implement front end changes to match the following specs: - According to Pavish `E2E` and `integration` test would be written in the same fashion on the frontend with the only difference being integration test would mock the backend API, so with regards to the terminology, we should be calling our current testing strategy with playwright as End-to-End testing. And Sean seems to be on the same page - Brent did not want to have a dogmatic approach to the naming convention, but he wanted to have a distinction. - Mukesh wanted to have distinction between integration test and E2E, where playwright should be used for writing E2E test and integration test should be based on jsdom and api mocks - - Mukesh expressed concerns that E2E test are flaky as it has to deal with unpredictable things like http calls, cache, async queues. Moreover as the app adds in additional layer like `async queue` or a `caching layer`, the set-up and teardown would become complex and increases both the development/maintanence time as well as the time to run the tests(which won't be much of a concern, as we run only specific test related to the feature we are working on during development). So we should be writing E2E tests that should test high level features like deleting a row and more specific tests like deleting multiple rows should be done with the integration layer. + - Mukesh expressed concerns that the E2E test is flaky as it has to deal with unpredictable things like http calls, cache, async queues. Moreover as the app adds in additional layer like `async queue` or a `caching layer`, the set-up and teardown would become complex and increases both the development/maintenence time as well as the time to run the tests(which won't be much of a concern, as we run only specific test related to the feature we are working on during development). So we should be writing E2E tests that should test high level features like deleting a row and more specific tests like deleting multiple rows should be done with the integration layer. - For time being, Mukesh agreed to have integration test written with UI automation using `playwright`. @@ -346,4 +346,4 @@ Notes: - Idea: Exporting data from Mathesar - Idea: Async infrastructure for Mathesar - Better done by core team, will not add - - We also need caching infrastructure, separately \ No newline at end of file + - We also need caching infrastructure, separately diff --git a/docs/team/meeting-notes/2022/03/2022-03.md b/docs/team/meeting-notes/2022/03/2022-03.md index 0ad4ba2f1..d83bf630e 100644 --- a/docs/team/meeting-notes/2022/03/2022-03.md +++ b/docs/team/meeting-notes/2022/03/2022-03.md @@ -71,7 +71,7 @@ Ghislaine went over the wireframes and people asked questions about it and made ## 2022-03-07 ### Column Identifier Discussion -Sync call to disuss on how to move forward with conflicting changes with Brent's work on grouping API and Mukesh's work on [Mathesar 896 Change records api parameters to use column id instead of name #1047](https://github.com/centerofci/mathesar/pull/1047). +Sync call to discuss on how to move forward with conflicting changes with Brent's work on grouping API and Mukesh's work on [Mathesar 896 Change records api parameters to use column id instead of name #1047](https://github.com/centerofci/mathesar/pull/1047). - **Participants:** Brent, Mukesh @@ -84,7 +84,7 @@ Sync call to disuss on how to move forward with conflicting changes with Brent's #### Notes: - Prefer to have attnums everywhere for consistency if possible. - View are treated as table in postgres and view columns are stored in similar fashion, with each view column having a attnum as reference. -- Creating auxillary hidden views without the knowledge of the users won't be a good idea as it would interfere with user's database and won't be optional like custom types. +- Creating auxiliary hidden views without the knowledge of the users won't be a good idea as it would interfere with user's database and won't be optional like custom types. - Suggestion to use Use autogenerated pseudo identifier for temporary aliased columns. - We could have a feature where the frontend could supply the alias of the column, this could solve the issue dom was talking about. But it would be a problem if only backend has information about a computed/aliased column. For example if a function generates a temporary column. diff --git a/docs/team/meeting-notes/2022/09/2022-09.md b/docs/team/meeting-notes/2022/09/2022-09.md index 8f1978dd2..2086b7f54 100644 --- a/docs/team/meeting-notes/2022/09/2022-09.md +++ b/docs/team/meeting-notes/2022/09/2022-09.md @@ -334,11 +334,11 @@ The discussion split into the following sub-topics: #### 1. If, and if so, how should Record Summaries be displayed in Data Explorer. -**When a user adds the id column of a table in the Data Explorer, should we show the id direcly as an integer or should we show a Record Summary?** +**When a user adds the id column of a table in the Data Explorer, should we show the id directly as an integer or should we show a Record Summary?** * Arguments supporting keeping id columns as integers and not showing Record Summary - Data Explorer is meant to allow the user form any query structure they want, and there are valid usecases where we may want to directly display the id, even if not the most common. - Users can add any column they want in the Data Explorer, which would make the purpose of Record Summaries moot within Data Explorer. - - Internally, calculting Record Summaries requires running a query. In this case, we'd run a query within a query, which isn't performant. + - Internally, calculating Record Summaries requires running a query. In this case, we'd run a query within a query, which isn't performant. * Arguments supporting showing Record Summaries as they shown are in tables - It would appear & function similar to tables maintaining uniformity across the product. - From the user standpoint, they can always expect the same behaviour, avoids confusion. diff --git a/docs/team/meeting-notes/2024/01/2024-01-22-release-check-in.md b/docs/team/meeting-notes/2024/01/2024-01-22-release-check-in.md index ac82344f2..0fc79a8f7 100644 --- a/docs/team/meeting-notes/2024/01/2024-01-22-release-check-in.md +++ b/docs/team/meeting-notes/2024/01/2024-01-22-release-check-in.md @@ -5,10 +5,10 @@ - Infra: we'll set it up and tear it down soon afterwards - Do we want separate database servers for everyone? - We'll use a single server for testing. We'll all prefix our database names with our own names, e.g. `sean_mathesar` -- Brent will set up a DB server separate from our interal server +- Brent will set up a DB server separate from our internal server - What pre-existing data should we have in place before upgrading? - lots of stuff going on in Django, e.g. Explorations - - What can go wrong? Migrations, Losing the connection between the service in its upgraded state and the correct user database โ€” anything that would prevent the service layer from connecting to the internal DB. + - What can go wrong? Migrations, losing the connection between the service in its upgraded state and the correct user database โ€” anything that would prevent the service layer from connecting to the internal DB. - Kriti: Do we really need to test all these different combinations? - Brent: We need to encourage people to move to our own latest Docker compose setup. If they've rolled their own then that's fine, but if they're running an older docker-compose setup, then they need to change their setup. - How aggressive do we want to be with changes for upgrades? diff --git a/docs/team/meeting-notes/2024/01/2024-01-29-staff-meeting.md b/docs/team/meeting-notes/2024/01/2024-01-29-staff-meeting.md index e837caf44..b474eedab 100644 --- a/docs/team/meeting-notes/2024/01/2024-01-29-staff-meeting.md +++ b/docs/team/meeting-notes/2024/01/2024-01-29-staff-meeting.md @@ -35,8 +35,8 @@ Build from scratch TODO items **blocking** release: - **Sean**: Modify "build from scratch" docs to bump the Node and npm versions up to newer versions - - Node: Atleast v18 - - npm: Atleast v9 + - Node: At least v18 + - npm: At least v9 - **Sean**: docs changes blocking release: - Add general disclaimer for upgrade instructions - Add special disclaimer for "build from scratch" upgrade instructions diff --git a/docs/team/meeting-notes/2024/01/2024-01-31-staff-meeting.md b/docs/team/meeting-notes/2024/01/2024-01-31-staff-meeting.md index d494ea030..d7170ae52 100644 --- a/docs/team/meeting-notes/2024/01/2024-01-31-staff-meeting.md +++ b/docs/team/meeting-notes/2024/01/2024-01-31-staff-meeting.md @@ -98,7 +98,7 @@ Meetings, purposes, timing - decide on architectural plans for backend performance improvements - have strategy discussions โ€” e.g. how we want to grow our user base, whether we want to pursue a SaaS offering - Permissions and worksheets - - Hard to sepearate these into independent discussions + - Hard to separate these into independent discussions - Pavish: want to prioritize making decisions on permissions first because we need that for the beta but we don't need worksheets for the beta - Kriti: yes, but we don't want to have to re-do permissions a third time. We need to take the worksheets discussion into account as well - Structure of meetings diff --git a/docs/team/meeting-notes/2024/02/2024-02-12-beta-planning-meeting.md b/docs/team/meeting-notes/2024/02/2024-02-12-beta-planning-meeting.md index c5f348d1a..609bfcd41 100644 --- a/docs/team/meeting-notes/2024/02/2024-02-12-beta-planning-meeting.md +++ b/docs/team/meeting-notes/2024/02/2024-02-12-beta-planning-meeting.md @@ -22,7 +22,7 @@ Goals of the meeting: - Big goal is to grow our user base. Currently this is hard because we can't recommend it to a lot of users (due to alpha status, performance issues). We need it to perform better before we can do that. - Brent: do we want forms for beta? Kriti: no. We should probably build this shortly after beta. - Order of operations - - Pavish: how much difference do we want/forsee between beta and 0.1? + - Pavish: how much difference do we want/foresee between beta and 0.1? - Kriti: not sure - Pavish: I would think we wouldn't want to add too many features in this window - Kriti: I'm not even thinking about v1.0 yet. We need more information before we make these decisions. @@ -40,7 +40,7 @@ Goals of the meeting: - Usability should also consider performance in different installation setups - Sean: not sure if it's worth making the beta depend on us moving our workflow over because we want to recommend Mathesar to people with pre-existing PG DBs. - Pavish: do we want to have a "user flow" like we did for the library demo? -- Kriti: we don't necesarily need to fix _every_ usability issue +- Kriti: we don't necessarily need to fix _every_ usability issue - Brent: it would be nice to have a use case that motivates us to use the DB outside of Mathesar too. - Kriti: it would be good for someone to come up with more scripts/stories soon - Kriti: I don't think the dogfooding has to be the end-all-be-all. It doesn't need to cover every feature. @@ -162,7 +162,7 @@ Goals of the meeting: - New features - View support -- Documentaion improvements (figure out requirements) +- Documentation improvements (figure out requirements) - Version numbering scheme - Docs updates vis-ร -vis versioning - do we want pip installation? diff --git a/docs/team/meeting-notes/2024/03/2024-03-06-staff-meeting.md b/docs/team/meeting-notes/2024/03/2024-03-06-staff-meeting.md index cb915f2e3..9b17d7b0f 100644 --- a/docs/team/meeting-notes/2024/03/2024-03-06-staff-meeting.md +++ b/docs/team/meeting-notes/2024/03/2024-03-06-staff-meeting.md @@ -16,7 +16,7 @@ ### What could've gone better - Sean: - - The amount of organizational overhead we have for each release still feels significantly larger than I would like to see for a task we're preforming every month. I'd like to continuing finding ways to streamline it. + - The amount of organizational overhead we have for each release still feels significantly larger than I would like to see for a task we're performing every month. I'd like to continuing finding ways to streamline it. - During the previous two releases, we've made the release very near the end of the month, having almost no time to spare. For me personally this time crunch adds significantly more stress to my overall experience as a Mathesar dev. In general I do not like missing deadlines or failing to meet goals. The idea of consistently having a "near miss" every month is uncomfortable for me. - Kriti: - Docker build issues took a while @@ -109,7 +109,7 @@ What to work on - Automate cutting release process - Error logging - - Brent: it would be good to figure out what we _want_ to do, even if we don't end up doing it for this releease. We'll work on figuring out the requirements. + - Brent: it would be good to figure out what we _want_ to do, even if we don't end up doing it for this release. We'll work on figuring out the requirements. - Brent would like to improve support for Python versions. Added. - i18n - Maybe we could have this is if we're able to receive the translations in time diff --git a/docs/team/meeting-notes/2024/05/2024-05-30-maintainer-meeting.md b/docs/team/meeting-notes/2024/05/2024-05-30-maintainer-meeting.md index 4d31faa55..b9966eeab 100644 --- a/docs/team/meeting-notes/2024/05/2024-05-30-maintainer-meeting.md +++ b/docs/team/meeting-notes/2024/05/2024-05-30-maintainer-meeting.md @@ -26,7 +26,7 @@ - Adds too much complexity, we don't want this for beta - Same applies to changes in hostname and port for database servers, we won't allow editing them for now - How do we handle DB role information when deleting databases? - - Users might assue that when they delete a database, all associated data โ€” including user roles, access control information, and passwords โ€” will be deleted automatically. + - Users might assume that when they delete a database, all associated data โ€” including user roles, access control information, and passwords โ€” will be deleted automatically. - We should ensure that when the user deletes the last database on a server, the system fully clears associated data. - We can use full cascade deletion. - We could use triggers or foreign key constraints to implement this. @@ -43,7 +43,7 @@ For example... - When creating a schema, we have an `if_not_exists` parameter implemented at the lower levels of code but not implemented at the higher levels of code. - From the UI, if I attempt to create a schema with a name that already exists, the UI shows the dreaded XHR error 500. From the user's perspective, I think this behavior is mostly fine. The error message should be improved, but the fact that it shows an error is perfectly acceptable. -- To me, this indicates that nobody has ever bumped into this from a user's perspective. And it shows that the lower level complexity is unecessary for our current product. I don't want to spend time carrying over that complexity through this refactor. +- To me, this indicates that nobody has ever bumped into this from a user's perspective. And it shows that the lower level complexity is unnecessary for our current product. I don't want to spend time carrying over that complexity through this refactor. If we can reduce complexity like that while we're wrangling all this code to fit the new RPC patterns, I think it would be a boon for our codebase and also reduce implementation time. diff --git a/docs/team/meeting-notes/2024/07/2024-07-16-maintainer-meeting.md b/docs/team/meeting-notes/2024/07/2024-07-16-maintainer-meeting.md index f8052d1d7..17eaca7b2 100644 --- a/docs/team/meeting-notes/2024/07/2024-07-16-maintainer-meeting.md +++ b/docs/team/meeting-notes/2024/07/2024-07-16-maintainer-meeting.md @@ -93,7 +93,7 @@ Not at the moment. > Do we ever combine filters with any logic other than `and`? -Yes. We have `and` and `or` at the higest level. We do not have nesting yet. +Yes. We have `and` and `or` at the highest level. We do not have nesting yet. ### Conclusion *Not recorded*. diff --git a/docs/team/meeting-notes/2024/07/2024-07-23-maintainer-meeting.md b/docs/team/meeting-notes/2024/07/2024-07-23-maintainer-meeting.md index e80965df7..350ea03bd 100644 --- a/docs/team/meeting-notes/2024/07/2024-07-23-maintainer-meeting.md +++ b/docs/team/meeting-notes/2024/07/2024-07-23-maintainer-meeting.md @@ -29,7 +29,7 @@ Questions to discuss: I've hit a small snag and I'd like opinions on the best approach to dealing with it... -Mathesar 0.1.7 allows users to create a new table without specifying a table name. Mathesar generates one automatically. Personally, I don't actualy like this feature. I'd rather Mathesar prompt me for a name because renaming it later requires extra steps. To support this feature, our `tables.add` API supports the ability to auto-generate a table name during creation. But the API only returns the table OID. The front end also needs to know the auto-generated name. Here are the ways I can think of to fix this: +Mathesar 0.1.7 allows users to create a new table without specifying a table name. Mathesar generates one automatically. Personally, I don't actually like this feature. I'd rather Mathesar prompt me for a name because renaming it later requires extra steps. To support this feature, our `tables.add` API supports the ability to auto-generate a table name during creation. But the API only returns the table OID. The front end also needs to know the auto-generated name. Here are the ways I can think of to fix this: - (A) Bodify the return value of `msar.add_mathesar_table` so that it returns something like `{ "oid": 12345, "name": "foo" }`. A downside here is that the return value would not be consistent with other return values. But this could be a good opportunity to discuss patterns around return values. Brent recent expressed a though/opinion that perhaps functions like this should return everything they can. diff --git a/docs/team/meeting-notes/2024/07/2024-07-24-permissions-retrospective.md b/docs/team/meeting-notes/2024/07/2024-07-24-permissions-retrospective.md index 7d8608147..2b629f33c 100644 --- a/docs/team/meeting-notes/2024/07/2024-07-24-permissions-retrospective.md +++ b/docs/team/meeting-notes/2024/07/2024-07-24-permissions-retrospective.md @@ -19,10 +19,10 @@ Let's talk about the product and design process for permissions - what went well * Initial group meetings were exhausting. - Explaining the entire thought process that went into a concept was quite hard and it wasn't possible in group calls. - Everyone approached the feature in a different mindset, which was great, but it also meant that I couldn't answer everyone in the way they approached the problem. 1:1s were more effective. -* Feedback that went in a different direction from what I had presented meant that I had to rethink a bunch of stuff to tie the user flow together and go through loop of presenting it to the team again. This is good. The problem was that, with the new concepts, I received completely opposite feedback from what everyone had communicated in the previous meetings. I had to keep going back to square 1 everytime this happened. +* Feedback that went in a different direction from what I had presented meant that I had to rethink a bunch of stuff to tie the user flow together and go through loop of presenting it to the team again. This is good. The problem was that, with the new concepts, I received completely opposite feedback from what everyone had communicated in the previous meetings. I had to keep going back to square 1 every time this happened. * Documentation took a lot of time and did not yield the team understanding I expected out of it. In contrast, designs were way useful in getting the ideas across. * 1:1s were way better than group calls, but this lead to people still having different ideas in their minds and the final group calls revealed issues and we had to rework on the concepts. - - I still think this was better and way less time consuming than having group calls everytime. + - I still think this was better and way less time consuming than having group calls every time. * I realized running meetings was a skill of its own and it's a hard skill to master. * Discussing raw concepts was very hard since they were fluid and I wasn't entirely confident and opinionated on the raw concepts themselves and my only focus was on the user experience. It was the opposite of discussing code related work and it took a while to get used to. * We encountered additional things we hadn't thought of in the design sessions, even after agreeing on the product spec. Often times in the design process with Ghislaine, we both felt pessimistic and had to pull back from feeling that. @@ -129,7 +129,7 @@ Let's talk about the product and design process for permissions - what went well - Brent: - Seconding Pavish. - Even if we start with a hypothetical user, its important to start a process without thinking of what page they are on, or what features they will use, even if this is lower level. - - As an engineering team we have a tendency to start prodcut and design process at low level. Users don't want to create roles, they want to create and store data and retrieve, use and analyse it. + - As an engineering team we have a tendency to start product and design process at low level. Users don't want to create roles, they want to create and store data and retrieve, use and analyse it. - Having user stories should be a crucial part of the design process. - We had user stories for permissions, but too late in the process. - Ghislaine: diff --git a/docs/team/worklogs/archive/2023-07/anish.md b/docs/team/worklogs/archive/2023-07/anish.md index 3c8a41da0..da34107da 100644 --- a/docs/team/worklogs/archive/2023-07/anish.md +++ b/docs/team/worklogs/archive/2023-07/anish.md @@ -24,11 +24,11 @@ ## 2023-07-25 -- Added tests for creating & droping for [SQL tests for schema ddl #3098](https://github.com/centerofci/mathesar/pull/3098) +- Added tests for creating & dropping for [SQL tests for schema ddl #3098](https://github.com/centerofci/mathesar/pull/3098) ## 2023-07-24 -- Figuring out how to start implementing the tests in the sql layer and which tests sholuld be pulled down from the python layer +- Figuring out how to start implementing the tests in the sql layer and which tests should be pulled down from the python layer ## 2023-07-21 @@ -84,4 +84,4 @@ - Met with Brent for discussing about the code organisation for [#2976](https://github.com/centerofci/mathesar/pull/2976) - Refactor [Cleaner consolidated logic for adding constraints #2976](https://github.com/centerofci/mathesar/pull/2976) - Help with a bug on matrix -- Mathesar weekly meet \ No newline at end of file +- Mathesar weekly meet diff --git a/docs/team/worklogs/archive/2023-07/pavish.md b/docs/team/worklogs/archive/2023-07/pavish.md index c7434d660..74bdb3f78 100644 --- a/docs/team/worklogs/archive/2023-07/pavish.md +++ b/docs/team/worklogs/archive/2023-07/pavish.md @@ -29,7 +29,7 @@ * Discussions ## 2023-07-24 -* Started and completed implementing a workaround for seperating app context of shared routes and normal authenticated routes on the frontend +* Started and completed implementing a workaround for separating app context of shared routes and normal authenticated routes on the frontend * Split the [large Shared tables PR](https://github.com/centerofci/mathesar/pull/3061) into two, and requested review for both - [Shareable links frontend - shared table consumer view](https://github.com/centerofci/mathesar/pull/3093) - [Shareable links backend - Models, APIs, bypass auth for table requests](https://github.com/centerofci/mathesar/pull/3092) diff --git a/docs/team/worklogs/archive/2023-08/brent.md b/docs/team/worklogs/archive/2023-08/brent.md index 74380a9dd..6144525a8 100644 --- a/docs/team/worklogs/archive/2023-08/brent.md +++ b/docs/team/worklogs/archive/2023-08/brent.md @@ -204,7 +204,7 @@ This was a short day for me - Fixed another bug with PR: [Properly detect identity columns #3125](https://github.com/centerofci/mathesar/pull/3125) ### Bugfixes -- PR [Repeat failed tests #3118](https://github.com/centerofci/mathesar/pull/3118) is merged after some chnages +- PR [Repeat failed tests #3118](https://github.com/mathesar-foundation/mathesar/pull/3118) is merged after some changes ### Ad-hoc - Helped Rajat with how to install `gettext` in containers for his translations project. diff --git a/docs/team/worklogs/archive/2023-08/ghislaine.md b/docs/team/worklogs/archive/2023-08/ghislaine.md index 16f10c054..558006d94 100644 --- a/docs/team/worklogs/archive/2023-08/ghislaine.md +++ b/docs/team/worklogs/archive/2023-08/ghislaine.md @@ -154,7 +154,7 @@ Today, I engaged in multiple conversations with team members about the use cases I'm currently working on preparing the surveys for our niche research. Additionally, I'm planning to have more conversations with other team members to gain their perspectives and insights on our work so far. -Aditionally, I worked on updating the design for creating the admin user. +Additionally, I worked on updating the design for creating the admin user. **Current Focus:** diff --git a/docs/team/worklogs/archive/2023-08/pavish.md b/docs/team/worklogs/archive/2023-08/pavish.md index 5bd9410fd..056758ca6 100644 --- a/docs/team/worklogs/archive/2023-08/pavish.md +++ b/docs/team/worklogs/archive/2023-08/pavish.md @@ -1,8 +1,8 @@ # Pavish's work log archive: 2023-08 ## 2023-08-31 -* Started reviewing [Load "en" translations parallely](https://github.com/centerofci/mathesar/pull/3102) -* Spent time finding issues/features to work on, when I'm not actively assiting on the projects +* Started reviewing [Load "en" translations parallely](https://github.com/mathesar-foundation/mathesar/pull/3102) +* Spent time finding issues/features to work on, when I'm not actively assisting on the projects * Chat with Brent and Ghislaine on further tasks for Postgres DB compatibility and Niche research projects ## 2023-08-28 to 2023-08-30 @@ -18,7 +18,7 @@ * 1-1 with Kriti ## 2023-08-24 -* Assiting manual QA for release +* Assisting manual QA for release * Added [DB list demo mode PR in the release](https://github.com/centerofci/mathesar/pull/3171) ## 2023-08-23 diff --git a/docs/team/worklogs/archive/2023-09/anish.md b/docs/team/worklogs/archive/2023-09/anish.md index 99f6290ba..ad6858c3b 100644 --- a/docs/team/worklogs/archive/2023-09/anish.md +++ b/docs/team/worklogs/archive/2023-09/anish.md @@ -50,9 +50,9 @@ ## 2023-09-18 - *Did nothing* (Cause I ran out of work to do) -- Waiting on the review for [#3055](https://github.com/centerofci/mathesar/pull/3055) +- Waiting on the review for [#3055](https://github.com/mathesar-foundation/mathesar/pull/3055) - Asked Dom if I can be of help with his ongoing project -- Will start working on the documentaion for Debian install [#3165](https://github.com/centerofci/mathesar/issues/3165) once a PR for docker installation is created as #3165 should follow the same template +- Will start working on the documentation for Debian install [#3165](https://github.com/centerofci/mathesar/issues/3165) once a PR for docker installation is created as #3165 should follow the same template ## 2023-09-15 @@ -60,12 +60,12 @@ ## 2023-09-14 -- Adressed requested changes for [#3055](https://github.com/centerofci/mathesar/pull/3055) +- Addressed requested changes for [#3055](https://github.com/mathesar-foundation/mathesar/pull/3055) ## 2023-09-13 - Sync with Mukesh -- Adressed requested changes for [#3170](https://github.com/centerofci/mathesar/pull/3170) +- Addressed requested changes for [#3170](https://github.com/mathesar-foundation/mathesar/pull/3170) ## 2023-09-12 diff --git a/docs/team/worklogs/archive/2023-09/pavish.md b/docs/team/worklogs/archive/2023-09/pavish.md index 8006823d2..95e755ae1 100644 --- a/docs/team/worklogs/archive/2023-09/pavish.md +++ b/docs/team/worklogs/archive/2023-09/pavish.md @@ -2,7 +2,7 @@ ## 2023-09-29 * Pondered more on user flows for E2E tests -* Responded to user raised GH ticket: [Disable shema modifications #3228](https://github.com/centerofci/mathesar/issues/3228) +* Responded to user raised GH ticket: [How to disable schema modifications #3228](https://github.com/mathesar-foundation/mathesar/issues/3228) * Core team event ## 2023-09-28 @@ -26,7 +26,7 @@ * Collected some more thoughts on Permission handling in Mathesar ## 2023-09-21 -* Re-reviewed (Load "en" translations parallely)[https://github.com/centerofci/mathesar/pull/3102] +* Re-reviewed [Load "en" translations parallely](https://github.com/mathesar-foundation/mathesar/pull/3102) - Thought about ways to deal with workarounds * Call with Rajat to discuss approaches and finalize all changes in this review round * Reviewed and merged [Survey banner PR](https://github.com/centerofci/mathesar-website/pull/93) @@ -88,4 +88,4 @@ ## 2023-09-01 * Core team event -* Spent time testing to find breaking features with preexisting postgres DB \ No newline at end of file +* Spent time testing to find breaking features with preexisting postgres DB diff --git a/docs/team/worklogs/archive/2023-10/kriti.md b/docs/team/worklogs/archive/2023-10/kriti.md index 6034bc846..123d3af0e 100644 --- a/docs/team/worklogs/archive/2023-10/kriti.md +++ b/docs/team/worklogs/archive/2023-10/kriti.md @@ -219,6 +219,6 @@ ## 2023-10-02 (Mon) *Partial day, migraine* -- Call with new lawyer abount various legal issues and next steps +- Call with new lawyer about various legal issues and next steps - Caught up with email, some responses - Some small administrative tasks and follow ups diff --git a/docs/team/worklogs/archive/2023-10/pavish.md b/docs/team/worklogs/archive/2023-10/pavish.md index 9cc3ef248..0275ee67c 100644 --- a/docs/team/worklogs/archive/2023-10/pavish.md +++ b/docs/team/worklogs/archive/2023-10/pavish.md @@ -116,6 +116,6 @@ ## 2023-10-02 * Checked out Calendly and SavvyCal features for team wide round-robin meetings * Responded to Kriti's mail on User interviews -* Conversations in user raised GH ticket: [Disable shema modifications #3228](https://github.com/centerofci/mathesar/issues/3228) +* Conversations in user raised GH ticket: [How to disable schema modifications #3228](https://github.com/mathesar-foundation/mathesar/issues/3228) * Took a look at [Fix visual regression of input appreaing disabled #3196](https://github.com/centerofci/mathesar/pull/3196) and [fix: read-only css for input #3197](https://github.com/centerofci/mathesar/pull/3197) - #3197 is better but it needs additional changes before merging. I'll be making the changes myself and merge it in. diff --git a/docs/team/worklogs/archive/dom.md b/docs/team/worklogs/archive/dom.md index 8c01334fb..be7bf833b 100644 --- a/docs/team/worklogs/archive/dom.md +++ b/docs/team/worklogs/archive/dom.md @@ -137,7 +137,7 @@ Away on sick leave. ### 2023-09-22 -- Submited draft PR for Paste API +- Submitted draft PR for Paste API - Fix GSoC summit travel arrangements, broken due to a cancellation ### 2023-09-21 diff --git a/docs/team/worklogs/archive/mukesh.md b/docs/team/worklogs/archive/mukesh.md index c9112f3fc..262ab7445 100644 --- a/docs/team/worklogs/archive/mukesh.md +++ b/docs/team/worklogs/archive/mukesh.md @@ -13,7 +13,7 @@ - Sync with Brent and Sean over the Database connection string UX - Attend the Users & Permission discussion - Reviewed [Fixed incomplete error responses in OpenAPI documentation for /datafiles/ endpoint](https://github.com/centerofci/mathesar/pull/3062) -- Reviewed [Implemeted extend schema decorator to document the error response for /databases/ endpoint](https://github.com/centerofci/mathesar/pull/3070) +- Reviewed [Implemented extend schema decorator to document the error response for /databases/ endpoint](https://github.com/centerofci/mathesar/pull/3070) - Partially review [Github action for uploading static assets to release](https://github.com/centerofci/mathesar/pull/3198) @@ -125,7 +125,7 @@ Had a day off due to sickness ## 2023-09-18 - Review [Postgres basic compatibility versions 13, 14, 15](https://github.com/centerofci/mathesar/pull/3206) and merge -- Test out the Postgres Docker image PR for compatability issues +- Test out the Postgres Docker image PR for compatibility issues - Progress on documentation for Docker images ## 2023-09-15 @@ -172,7 +172,7 @@ Had a day off due to sickness - Review "Database credentials page" design spec ## 2023-09-07 -- Check in with Brent to discuss Postgres 15 compatiblity issues, debian package review +- Check in with Brent to discuss Postgres 15 compatibility issues, debian package review - Check in with Pavish to discuss manifest.json location - Review backend PR for adding database credential API @@ -410,7 +410,7 @@ Had a day off due to sickness - Contacted helpers for the Installation Improvement 0.1.3 project to get their confirmation - Updated the Installation Improvement 0.1.3 project specs and sent out email of the changes made - Started working on the backend issues for the super user creation page -- Intergrate local IDE workspace with the workflow logs to make worklog updates easier +- Integrate local IDE workspace with the workflow logs to make worklog updates easier ## 2023-07-17 @@ -440,7 +440,7 @@ Had a day off due to sickness ## 2023-07-11 -- Started writing email for the potential solution for simplifying Installation. Couln't complete before the meeting +- Started writing email for the potential solution for simplifying Installation. Couldn't complete before the meeting - Attend Installation IV meeting - Sync call with Rajat to discuss Internationalization implementation in Django templates. diff --git a/docs/team/worklogs/archive/rajat.md b/docs/team/worklogs/archive/rajat.md index 11ca391e9..57f695e11 100644 --- a/docs/team/worklogs/archive/rajat.md +++ b/docs/team/worklogs/archive/rajat.md @@ -73,11 +73,11 @@ - Repo-admin work - Synced with Mukesh regarding missing links in database ui PR. - Replied to retro e-mail for the last cycle. -- Tackled review feedback & made ready for review - [[i18n] Load "en" translations parallely](https://github.com/centerofci/mathesar/pull/3102) +- Tackled review feedback & made ready for review - [[i18n] Load "en" translations parallely](https://github.com/mathesar-foundation/mathesar/pull/3102) ## 2023-10-06 -- Worked on review feedback for - [[i18n] Load "en" translations parallely](https://github.com/centerofci/mathesar/pull/3102) +- Worked on review feedback for - [[i18n] Load "en" translations parallely](https://github.com/mathesar-foundation/mathesar/pull/3102) ## 2023-10-05 diff --git a/docs/team/worklogs/sean.md b/docs/team/worklogs/sean.md index 1dfc5fad9..d343f90ad 100644 --- a/docs/team/worklogs/sean.md +++ b/docs/team/worklogs/sean.md @@ -31,7 +31,7 @@ ## 2023-12-07 Thursday -- Work on improving code within [Added drag functionality to update precendence for sort condition](https://github.com/mathesar-foundation/mathesar/pull/3316). +- Work on improving code within [Added drag functionality to update precedence for sort condition](https://github.com/mathesar-foundation/mathesar/pull/3316). ## 2023-12-06 Wednesday @@ -42,7 +42,7 @@ ## 2023-12-05 Tuesday -- Some continued work reviewing [Added drag functionality to update precendence for sort condition](https://github.com/mathesar-foundation/mathesar/pull/3316) +- Some continued work reviewing [Added drag functionality to update precedence for sort condition](https://github.com/mathesar-foundation/mathesar/pull/3316) - Monthly ticket approval meeting - Work on re-organizing ticket labels @@ -79,7 +79,7 @@ _(Very short day due to trip prep and lack of childcare)_ - Weigh in on chat system email thread - Continued progress on New DB connection form, including a [draft PR](https://github.com/mathesar-foundation/mathesar/pull/3319) - User call -- Preliminary review of [Added drag functionality to update precendence for sort condition](https://github.com/mathesar-foundation/mathesar/pull/3316#pullrequestreview-1743475745) +- Preliminary review of [Added drag functionality to update precedence for sort condition](https://github.com/mathesar-foundation/mathesar/pull/3316#pullrequestreview-1743475745) ## 2023-11-20 Monday