Skip to content

Instantly share code, notes, and snippets.

@thedeveloperr

thedeveloperr/gsoc_2019_zulip_workproduct.md

Last active January 9, 2020 14:10
Show Gist options
  • Save thedeveloperr/4c2630545b4c052deb45a7d86077e75c to your computer and use it in GitHub Desktop.
Save thedeveloperr/4c2630545b4c052deb45a7d86077e75c to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. thedeveloperr revised this gist Aug 25, 2019. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions gsoc_2019_zulip_workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@
    # Work Product Document for Zulip open source project as GSoC 2019 student developer.
    **Mohit Gupta** | [Github](https://github.com/thedeveloperr)
    **Mohit Gupta** | [Github](https://github.com/thedeveloperr) | [Linkedin](https://www.linkedin.com/in/mohit-gupta-developer/)

    **Areas worked in:** Search, Message View, group PMs, bots, production

    @@ -8,8 +8,8 @@ This gist contains work done during Google Summer of Code 2019 with Zulip open s
    * Zulip's main frontend webapp which is in Javascript
    * Zulip backend server which uses Python's Django, sqlalchemy, tornado, rabbitmq.

    I want to thank my GSoC's assigned mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and help enabled me to complete my work successfully.
    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to the whole Zulip community at chat.zulip.org for their help during my GSoC journey. It's because of you all I’ve had an awesome summer. This whole experience helped me to grow and improve as a Software Developer for which I am grateful.
    I want to wiht my whole heart thank my GSoC's mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and regular meetings helped me to complete my work successfully.
    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for their guidance and code reviews. Thanks to the whole Zulip community at chat.zulip.org for their help during my GSoC journey. It's because of you all I’ve had an awesome summer. This whole experience helped me to grow and improve as a Software Developer for which I am grateful.

    ## Work summary

  2. thedeveloperr renamed this gist Aug 23, 2019. 1 changed file with 0 additions and 0 deletions.
    0 workproduct.md → gsoc_2019_zulip_workproduct.md
    View file
    File renamed without changes.
  3. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@
    **Areas worked in:** Search, Message View, group PMs, bots, production

    ## Introduction
    This gist contains work done during Google Summer of Code 2019 with Zulip open source project. Most of my work is fullstack. I Worked both on
    This gist contains work done during Google Summer of Code 2019 with Zulip open source project. Most of my work is fullstack. I Worked both on:
    * Zulip's main frontend webapp which is in Javascript
    * Zulip backend server which uses Python's Django, sqlalchemy, tornado, rabbitmq.

  4. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -26,7 +26,7 @@ I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[
    * **PR: [filter: Add more narrow filters that cannot mark messages as read. #12849](https://github.com/zulip/zulip/pull/12849)**
    * Status: Open and waiting for review.
    * Follow up based on [comment on PR #12747](https://github.com/zulip/zulip/pull/12747#issuecomment-510195186). Adds more narrows where message is not marked as read.
    * As a product decision, the team decided to expand more search views/narrows where message should not be marked as read. Eg. while searching for messages which has link using `has:link` operator or search messages where you were mentioned `is:mentioned` using operator. Most of the time was spent in wiriting exhaustive tests so as to ensure everything is working. This feature had many possible test cases. Exhaustive testing will ensure that no issue will crop up now and in future.
    * As a product decision, the team decided to expand more search views/narrows where message should not be marked as read. Eg. while searching for messages which has link using `has:link` operator or search messages where you were mentioned `is:mentioned` using operator. Most of the time was spent in writing exhaustive tests so as to ensure everything is working. This feature had many possible test cases. Exhaustive testing will ensure that no issue will crop up now and in future.
    * Unmerged commits: https://github.com/zulip/zulip/pull/12849/commits

    * **PR: [narrow: Fix to show last message in narrow when narrow allows.#12847](https://github.com/zulip/zulip/pull/12847)**
  5. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -7,8 +7,8 @@
    This gist contains work done during Google Summer of Code 2019 with Zulip open source project. Most of my work is fullstack. I Worked both on
    * Zulip's main frontend webapp which is in Javascript
    * Zulip backend server which uses Python's Django, sqlalchemy, tornado, rabbitmq.
    I want to thank my GSoC's assigned mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and help enabled me to complete my work successfully.

    I want to thank my GSoC's assigned mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and help enabled me to complete my work successfully.
    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to the whole Zulip community at chat.zulip.org for their help during my GSoC journey. It's because of you all I’ve had an awesome summer. This whole experience helped me to grow and improve as a Software Developer for which I am grateful.

    ## Work summary
  6. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,7 +9,7 @@ This gist contains work done during Google Summer of Code 2019 with Zulip open s
    * Zulip backend server which uses Python's Django, sqlalchemy, tornado, rabbitmq.
    I want to thank my GSoC's assigned mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and help enabled me to complete my work successfully.

    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to whole Zulip community at chat.zulip.org for their help during my GSoC journey. I’ve had an awesome and full of learning summer thanks to Zulip and GSoC.
    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to the whole Zulip community at chat.zulip.org for their help during my GSoC journey. It's because of you all I’ve had an awesome summer. This whole experience helped me to grow and improve as a Software Developer for which I am grateful.

    ## Work summary

  7. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,7 +9,7 @@ This gist contains work done during Google Summer of Code 2019 with Zulip open s
    * Zulip backend server which uses Python's Django, sqlalchemy, tornado, rabbitmq.
    I want to thank my GSoC's assigned mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and help enabled me to complete my work successfully.

    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to whole Zulip community at chat.zulip.org for their help during my GSoC journey. I’ve had an awesome summer thanks to Zulip community.
    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to whole Zulip community at chat.zulip.org for their help during my GSoC journey. I’ve had an awesome and full of learning summer thanks to Zulip and GSoC.

    ## Work summary

  8. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 11 additions and 1 deletion.
    12 changes: 11 additions & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -3,6 +3,16 @@

    **Areas worked in:** Search, Message View, group PMs, bots, production

    ## Introduction
    This gist contains work done during Google Summer of Code 2019 with Zulip open source project. Most of my work is fullstack. I Worked both on
    * Zulip's main frontend webapp which is in Javascript
    * Zulip backend server which uses Python's Django, sqlalchemy, tornado, rabbitmq.
    I want to thank my GSoC's assigned mentors **[Yago González](https://github.com/YagoGG)**, **[David Rosa](https://github.com/drrosa)** Your patience, advice and help enabled me to complete my work successfully.

    I also want to thank Zulip's **[Tim Abbott](https://github.com/timabbott)**, **[Rishi Gupta](https://github.com/rishig)** for your guidance and code reviews. Thanks to whole Zulip community at chat.zulip.org for their help during my GSoC journey. I’ve had an awesome summer thanks to Zulip community.

    ## Work summary

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
    * Status: Closed and Merged as commit [e5482ad](https://github.com/zulip/zulip/commit/e5482adec0b4e49f1619fb0b3069929fa9893400)
    * Solves Issue [#8859](https://github.com/zulip/zulip/issues/8859).Right now in zulip past message history can be searched in single stream one at a time. But This PR provides user ability to search all of the organisation's public streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    @@ -48,7 +58,7 @@
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have multiple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with multiple api key model ( See https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt a lot about git's cherry picking, searching old commits, diffs.
    * In the second work period, merge conflicts again occurred with my PR 12511. I had to rebase and fix new set of failing tests. This experience gave me insights how a fast moving project can easily break previous unmerged work.
    * In the second work period, merge conflicts again occurred with my PR 12511. I had to rebase and fix new set of failing tests. Thanks to a fellow GSoC student [Hemanth](https://github.com/Hypro999) for helping me fix these undocumented tests. This experience gave me insights how a fast moving project can easily break previous unmerged work.
    * Unmerged Commits: https://github.com/zulip/zulip/pull/12511/commits

    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
  9. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    # Work Product Document for Zulip open source project as GSoC 2019 student developer.
    ### Zulip server - powerful open source team chat
    **Username:**
    **Mohit Gupta** | [Github](https://github.com/thedeveloperr)

    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
  10. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 4 additions and 2 deletions.
    6 changes: 4 additions & 2 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,13 +1,15 @@
    # Work Product Document for Zulip open source project as GSoC 2019 student developer.
    ### Zulip server - powerful open source team chat
    ### Zulip server - powerful open source team chat
    **Username:**
    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
    * Status: Closed and Merged as commit [e5482ad](https://github.com/zulip/zulip/commit/e5482adec0b4e49f1619fb0b3069929fa9893400)
    * Solves Issue [#8859](https://github.com/zulip/zulip/issues/8859).Right now in zulip past message history can be searched in single stream one at a time. But This PR provides user ability to search all of the organisation's public streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both.

    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete and merged. This feature I think completes a feature that is needed in a team chat software. Ability to search whole organisation message history will allow users to find information that have been shared already in past even if it is hidden in an unsubscibed stream within organisation.
    * Work for `streams:subscribed` remains and will be done in a followup PR, it's being tracked as issue [#13052](https://github.com/zulip/zulip/issues/13052)

  11. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,7 +8,7 @@
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete and merged. This feature I think completes a feature that is needed in a team chat software. Ability to search whole organisation message history will allow users to find information that have been shared already in past which might be hidden in an unsubscibed stream within organisation.
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete and merged. This feature I think completes a feature that is needed in a team chat software. Ability to search whole organisation message history will allow users to find information that have been shared already in past even if it is hidden in an unsubscibed stream within organisation.
    * Work for `streams:subscribed` remains and will be done in a followup PR, it's being tracked as issue [#13052](https://github.com/zulip/zulip/issues/13052)

    * **PR: [filter: Add more narrow filters that cannot mark messages as read. #12849](https://github.com/zulip/zulip/pull/12849)**
  12. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
    * Status: Closed and Merged as [e5482ad](https://github.com/zulip/zulip/commit/e5482adec0b4e49f1619fb0b3069929fa9893400)
    * Status: Closed and Merged as commit [e5482ad](https://github.com/zulip/zulip/commit/e5482adec0b4e49f1619fb0b3069929fa9893400)
    * Solves Issue [#8859](https://github.com/zulip/zulip/issues/8859).Right now in zulip past message history can be searched in single stream one at a time. But This PR provides user ability to search all of the organisation's public streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    @@ -15,10 +15,12 @@
    * Status: Open and waiting for review.
    * Follow up based on [comment on PR #12747](https://github.com/zulip/zulip/pull/12747#issuecomment-510195186). Adds more narrows where message is not marked as read.
    * As a product decision, the team decided to expand more search views/narrows where message should not be marked as read. Eg. while searching for messages which has link using `has:link` operator or search messages where you were mentioned `is:mentioned` using operator. Most of the time was spent in wiriting exhaustive tests so as to ensure everything is working. This feature had many possible test cases. Exhaustive testing will ensure that no issue will crop up now and in future.
    * Unmerged commits: https://github.com/zulip/zulip/pull/12849/commits

    * **PR: [narrow: Fix to show last message in narrow when narrow allows.#12847](https://github.com/zulip/zulip/pull/12847)**
    * Status: Open and waiting for review (The code paths are complicated and need in depth review).
    * Solves a feature that was supposed to properly work in last PR. In PR [#12747](https://github.com/zulip/zulip/pull/12747) there was a situtation which required not to show unread message first but show last message. All logic and functions were implemented and called but UI was not updating. In initial manual testing the all other situations were tested except this. There was no automated test to check this new situation so this problem was gone unnoticed. This PR basically fixes it and adds test to ensure this kind of issue is caught in future. Lesson: Exhaustive automated tests ensures that feature functions properly, mistakes are caught early and feature won't break in future.
    * Unmerged commits: https://github.com/zulip/zulip/pull/12847/commits

    * **PR: [search: Don't mark messages as read in search narrow. #12747](https://github.com/zulip/zulip/pull/12747)**
    * Status: Merged and Closed.
  13. thedeveloperr revised this gist Aug 23, 2019. 1 changed file with 4 additions and 3 deletions.
    7 changes: 4 additions & 3 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -3,12 +3,13 @@
    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
    * Status: Open and Reviewed once but spec got updated so making changes according to new specs. Original spec was complete and tested. New spec. is also close to completion.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issues/8859).Right now in zulip past message history can be searched in one stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * Status: Closed and Merged as [e5482ad](https://github.com/zulip/zulip/commit/e5482adec0b4e49f1619fb0b3069929fa9893400)
    * Solves Issue [#8859](https://github.com/zulip/zulip/issues/8859).Right now in zulip past message history can be searched in single stream one at a time. But This PR provides user ability to search all of the organisation's public streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete. Work for `streams:subscribed` remains. This feature I think completes a feature that is needed in a team chat software. Ability to search whole organisation message history will allow users to find information that have been shared already in past which might be hidden in an unsubscibed stream within organisation.
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete and merged. This feature I think completes a feature that is needed in a team chat software. Ability to search whole organisation message history will allow users to find information that have been shared already in past which might be hidden in an unsubscibed stream within organisation.
    * Work for `streams:subscribed` remains and will be done in a followup PR, it's being tracked as issue [#13052](https://github.com/zulip/zulip/issues/13052)

    * **PR: [filter: Add more narrow filters that cannot mark messages as read. #12849](https://github.com/zulip/zulip/pull/12849)**
    * Status: Open and waiting for review.
  14. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -49,7 +49,7 @@
    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time was spent writing and correcting Unit test because of a buggy test endpoint. Intially wrote test using API endpoint that was used by existing tests already in the main codebase. But those pre existing testing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bugs in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow the principle of "Leave the code better than you found it"
    * Most of time was spent writing and correcting Unit test because of a buggy test endpoint. Intially wrote test using API endpoint that was used by existing tests already in the main codebase. But those pre existing testing code were buggy. I fixed those tests in commit [d60f6c9](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bugs in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow the principle of "Leave the code better than you found it"
    * Merged Commits: [d60f6c9](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49), [a98447b](https://github.com/zulip/zulip/commit/a98447b31200a815c331b02686a92a836393d06e)

    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
  15. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -42,7 +42,7 @@
    * **PR: [Cleaned and Rebased version of PR #10102 Multiple api keys #12511](https://github.com/zulip/zulip/pull/12511)**
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have multiple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with multiple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt a lot about git's cherry picking, searching old commits, diffs.
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have multiple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with multiple api key model ( See https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt a lot about git's cherry picking, searching old commits, diffs.
    * In the second work period, merge conflicts again occurred with my PR 12511. I had to rebase and fix new set of failing tests. This experience gave me insights how a fast moving project can easily break previous unmerged work.
    * Unmerged Commits: https://github.com/zulip/zulip/pull/12511/commits

  16. thedeveloperr revised this gist Aug 22, 2019. No changes.
  17. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -29,7 +29,7 @@
    * Status: Merged and Closed.
    * Solves issue [#12601](https://github.com/zulip/zulip/issues/12601) and [#12593](https://github.com/zulip/zulip/issues/12593)
    * Intially [#12593](https://github.com/zulip/zulip/issues/12593) seemed to be a backend bug but while Investigating bug lead to two completely different bugs. One was frontend bug (source was very hard to find) another as expected a backend one. [Investigation details](https://chat.zulip.org/#narrow/stream/9-issues/topic/.2312593.20DMs.20with.20deactivated.20users)
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of the core data model of zulip the `Recipient` Model. I got a chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in a single PR using four commits. The refactor experience took me to one of the core data model of zulip the `Recipient` Model. I got a chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.
    * Merged Commits: [48786](https://github.com/zulip/zulip/commit/487861554fce3991bd1405a31226da8c335116ed), [c971576](https://github.com/zulip/zulip/commit/c971576b007c3d3ef3af4aed4e8621c4a1be634d), [00cdba2](https://github.com/zulip/zulip/commit/00cdba2090060258034bee091655b926f49bd474), [45f87ff](https://github.com/zulip/zulip/commit/45f87ff44b6fa9aaaa7d4a530d4831c5d1a6b941)

    * **PR: [WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
  18. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -17,7 +17,7 @@

    * **PR: [narrow: Fix to show last message in narrow when narrow allows.#12847](https://github.com/zulip/zulip/pull/12847)**
    * Status: Open and waiting for review (The code paths are complicated and need in depth review).
    * Solves a feature that was supposed to properly work in last PR. In PR [#12747](https://github.com/zulip/zulip/pull/12747) there was a feature not to show unread message first but show last message. All logic and functions were implemented and called but UI was not updating. In initial manual testing the situation of showing unread message first was tested but showing last message was not tested when unread message were present. Also there was no automated test to check this situation so this problem was gone unnoticed. This PR basically fixes it and adds test to ensure this kind of issue is caught in future. Lesson: Exhaustive tests ensures that feature functions properly and won't break in future.
    * Solves a feature that was supposed to properly work in last PR. In PR [#12747](https://github.com/zulip/zulip/pull/12747) there was a situtation which required not to show unread message first but show last message. All logic and functions were implemented and called but UI was not updating. In initial manual testing the all other situations were tested except this. There was no automated test to check this new situation so this problem was gone unnoticed. This PR basically fixes it and adds test to ensure this kind of issue is caught in future. Lesson: Exhaustive automated tests ensures that feature functions properly, mistakes are caught early and feature won't break in future.

    * **PR: [search: Don't mark messages as read in search narrow. #12747](https://github.com/zulip/zulip/pull/12747)**
    * Status: Merged and Closed.
  19. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
    * Status: Open and Reviewed once but spec got updated so making changes according to new specs. Original spec was complete and tested. New spec. is also close to completion.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issue/8859).Right now in zulip past message history can be searched in one stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issues/8859).Right now in zulip past message history can be searched in one stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both
  20. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@
    ### Zulip server - powerful open source team chat
    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/#12999)**
    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/12999)**
    * Status: Open and Reviewed once but spec got updated so making changes according to new specs. Original spec was complete and tested. New spec. is also close to completion.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issue/8859).Right now in zulip past message history can be searched in one stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
  21. thedeveloperr revised this gist Aug 22, 2019. 1 changed file with 13 additions and 13 deletions.
    26 changes: 13 additions & 13 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,22 +2,22 @@
    ### Zulip server - powerful open source team chat
    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [search: Add is:public-stream to search entire history of public streams. #12999](https://github.com/zulip/zulip/pull/#12999)**
    * **PR: [streams:public and streams:subscribed to search entire history of organisation. #12999](https://github.com/zulip/zulip/pull/#12999)**
    * Status: Open and Reviewed once but spec got updated so making changes according to new specs. Original spec was complete and tested. New spec. is also close to completion.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issue/8859).Right in zulip past message history can be searched in a single stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before user joint the organisation.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issue/8859).Right now in zulip past message history can be searched in one stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before the user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete. Work for `streams:subscribed` remains. This feature I think completes a feature that is needed in a team chat software. Ablity to search whole orgnaisation message history will allow users to find information that have been shared already in past which might had been hidden in a unsubscibed stream within organisation.
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete. Work for `streams:subscribed` remains. This feature I think completes a feature that is needed in a team chat software. Ability to search whole organisation message history will allow users to find information that have been shared already in past which might be hidden in an unsubscibed stream within organisation.

    * **PR: [filter: Add more narrow filters that cannot mark messages as read. #12849](https://github.com/zulip/zulip/pull/12849)**
    * Status: Open and waiting for review.
    * Follow up based on [comment on PR #12747](https://github.com/zulip/zulip/pull/12747#issuecomment-510195186). Adds more narrows where message is not marked as read.
    * As a product decision, Team decided to expand more search views/narrows where message should not be marked as read. Eg. while searching for messages which has link using `has:link` operator or search messages where you were mentioned `is:mentioned` using operator. Most of time went into exhaustive tests so as to ensure everything is working. This feature have many possible cases. Exhaustive testing ensures that no issue crop up now and in future.
    * As a product decision, the team decided to expand more search views/narrows where message should not be marked as read. Eg. while searching for messages which has link using `has:link` operator or search messages where you were mentioned `is:mentioned` using operator. Most of the time was spent in wiriting exhaustive tests so as to ensure everything is working. This feature had many possible test cases. Exhaustive testing will ensure that no issue will crop up now and in future.

    * **PR: [narrow: Fix to show last message in narrow when narrow allows.#12847](https://github.com/zulip/zulip/pull/12847)**
    * Status: Open and waiting for review (The code paths are complicated and need in depth review).
    * Solves a feature that was supposed to properly work in last PR. In PR [#12747](https://github.com/zulip/zulip/pull/12747) there was a feature not to show unread message first but show last message. All logic and functions were implemented and called but was UI was not updating. In initial manual testing the situation of showing unread message first was tested but showing last message was not tested when unread message were present. Also there was no automated test to check this situation so this problem gone unnoticed. . This PR basically fixes it and adds to test to ensure this kind of issue is caught in future. Lesson: Exhaustive automated test will ensure features working in future and present.
    * Solves a feature that was supposed to properly work in last PR. In PR [#12747](https://github.com/zulip/zulip/pull/12747) there was a feature not to show unread message first but show last message. All logic and functions were implemented and called but UI was not updating. In initial manual testing the situation of showing unread message first was tested but showing last message was not tested when unread message were present. Also there was no automated test to check this situation so this problem was gone unnoticed. This PR basically fixes it and adds test to ensure this kind of issue is caught in future. Lesson: Exhaustive tests ensures that feature functions properly and won't break in future.

    * **PR: [search: Don't mark messages as read in search narrow. #12747](https://github.com/zulip/zulip/pull/12747)**
    * Status: Merged and Closed.
    @@ -29,31 +29,31 @@
    * Status: Merged and Closed.
    * Solves issue [#12601](https://github.com/zulip/zulip/issues/12601) and [#12593](https://github.com/zulip/zulip/issues/12593)
    * Intially [#12593](https://github.com/zulip/zulip/issues/12593) seemed to be a backend bug but while Investigating bug lead to two completely different bugs. One was frontend bug (source was very hard to find) another as expected a backend one. [Investigation details](https://chat.zulip.org/#narrow/stream/9-issues/topic/.2312593.20DMs.20with.20deactivated.20users)
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of core data model of zulip the `Recipient` Model. I got chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of the core data model of zulip the `Recipient` Model. I got a chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.
    * Merged Commits: [48786](https://github.com/zulip/zulip/commit/487861554fce3991bd1405a31226da8c335116ed), [c971576](https://github.com/zulip/zulip/commit/c971576b007c3d3ef3af4aed4e8621c4a1be634d), [00cdba2](https://github.com/zulip/zulip/commit/00cdba2090060258034bee091655b926f49bd474), [45f87ff](https://github.com/zulip/zulip/commit/45f87ff44b6fa9aaaa7d4a530d4831c5d1a6b941)

    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * **PR: [WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * Status: Open and Work in progress due to some doubts in specs.
    * Solves issue [#12424](https://github.com/zulip/zulip/issues/12424)
    * A refactor prep. commits was merged [db3d81613bf0530db](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d)
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR still is stuck on that stage because I am still waiting for the doubts to be resolved.
    * Merged Commits: [db3d816](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d), Unmerged: Unmerged Commits: https://github.com/zulip/zulip/pull/12589/commits
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR is stuck because I am still waiting for the doubts to be resolved.
    * Merged Commits: [db3d816](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d), Unmerged Commits: https://github.com/zulip/zulip/pull/12589/commits

    * **PR: [Cleaned and Rebased version of PR #10102 Multiple api keys #12511](https://github.com/zulip/zulip/pull/12511)**
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have mulitple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with mulitple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt alot about cherry picking, searching old commits, diffs practically.
    * In the second work period, merge conflicts again occured with my PR 12511. I had to rebase and fix new set of failing test. This experience gave me insights how a fast moving project can easily break previous unmerged work.
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have multiple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with multiple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt a lot about git's cherry picking, searching old commits, diffs.
    * In the second work period, merge conflicts again occurred with my PR 12511. I had to rebase and fix new set of failing tests. This experience gave me insights how a fast moving project can easily break previous unmerged work.
    * Unmerged Commits: https://github.com/zulip/zulip/pull/12511/commits

    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing and correcting Unit test because of buggy test endpoint. Intially wrote test using API endpoint that were used by similar tests already in the main codebase. But those pre existing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bug in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow principle of "Leave the code better than you found it"
    * Most of time was spent writing and correcting Unit test because of a buggy test endpoint. Intially wrote test using API endpoint that was used by existing tests already in the main codebase. But those pre existing testing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bugs in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow the principle of "Leave the code better than you found it"
    * Merged Commits: [d60f6c9](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49), [a98447b](https://github.com/zulip/zulip/commit/a98447b31200a815c331b02686a92a836393d06e)

    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged and Closed
    * Solves issue [#11956](https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to the batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experience to simulate different conditions in tests.
    * Merged Commits: [1902f52](https://github.com/zulip/zulip/commit/1902f5210c41fc730e125dc03cbafd168e7d4e9d)
  22. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -50,10 +50,10 @@
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing and correcting Unit test because of buggy test endpoint. Intially wrote test using API endpoint that were used by similar tests already in the main codebase. But those pre existing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bug in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow principle of "Leave the code better than you found it"
    * Merged Commits: [d60f6c9](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49), [a98447b](https://github.com/zulip/zulip/commit/a98447b31200a815c331b02686a92a836393d06e),
    * Merged Commits: [d60f6c9](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49), [a98447b](https://github.com/zulip/zulip/commit/a98447b31200a815c331b02686a92a836393d06e)

    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged and Closed
    * Solves issue [#11956](https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.
    * Merged Commits: [1902f52](https://github.com/zulip/zulip/commit/1902f5210c41fc730e125dc03cbafd168e7d4e9d), []
    * Merged Commits: [1902f52](https://github.com/zulip/zulip/commit/1902f5210c41fc730e125dc03cbafd168e7d4e9d)
  23. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 12 additions and 3 deletions.
    15 changes: 12 additions & 3 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,7 @@
    ## PR I worked on
    # Work Product Document for Zulip open source project as GSoC 2019 student developer.
    ### Zulip server - powerful open source team chat
    **Areas worked in:** Search, Message View, group PMs, bots, production

    * **PR: [search: Add is:public-stream to search entire history of public streams. #12999](https://github.com/zulip/zulip/pull/#12999)**
    * Status: Open and Reviewed once but spec got updated so making changes according to new specs. Original spec was complete and tested. New spec. is also close to completion.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issue/8859).Right in zulip past message history can be searched in a single stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before user joint the organisation.
    @@ -20,31 +23,37 @@
    * Status: Merged and Closed.
    * Solves issue [#12556](https://github.com/zulip/zulip/issues/12556). Basic thing it solved was to not mark new unread messages as read when they appear in search query for an older conversation.
    * This was a pretty high priority and highly requested feature by community, both Tim and Yago were excited to see it happen. The main work was finding relevant places to make changes in existing codebase. Zulip's frontend is old and big, some places the code is too complicated so it was a time consuming process to read the existing code and figure out where to make changes. Every new feature required new code files and lines to be read. The actual logic was simple. After some experience, writing unit tests was also not that difficult.
    * Merged commits: [6ec40cf](https://github.com/zulip/zulip/commit/6ec40cf9a0ac32407013e2f9f6a337082e68e249), [648a60](https://github.com/zulip/zulip/commit/648a60baf63f9afade83148bd9ae1fc480510178)

    * **PR: [Fix searching and viewing Group PM and refactor of by_pm_with #12661](https://github.com/zulip/zulip/pull/12661)**
    * Status: Merged and Closed.
    * Solves issue [#12601](https://github.com/zulip/zulip/issues/12601) and [#12593](https://github.com/zulip/zulip/issues/12593)
    * Intially [#12593](https://github.com/zulip/zulip/issues/12593) seemed to be a backend bug but while Investigating bug lead to two completely different bugs. One was frontend bug (source was very hard to find) another as expected a backend one. [Investigation details](https://chat.zulip.org/#narrow/stream/9-issues/topic/.2312593.20DMs.20with.20deactivated.20users)
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of core data model of zulip the `Recipient` Model. I got chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of core data model of zulip the `Recipient` Model. I got chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.
    * Merged Commits: [48786](https://github.com/zulip/zulip/commit/487861554fce3991bd1405a31226da8c335116ed), [c971576](https://github.com/zulip/zulip/commit/c971576b007c3d3ef3af4aed4e8621c4a1be634d), [00cdba2](https://github.com/zulip/zulip/commit/00cdba2090060258034bee091655b926f49bd474), [45f87ff](https://github.com/zulip/zulip/commit/45f87ff44b6fa9aaaa7d4a530d4831c5d1a6b941)

    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * Status: Open and Work in progress due to some doubts in specs.
    * Solves issue [#12424](https://github.com/zulip/zulip/issues/12424)
    * A refactor prep. commits was merged [db3d81613bf0530db](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d)
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR still is stuck on that stage because I am still waiting for the doubts to be resolved.
    * Merged Commits: [db3d816](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d), Unmerged: Unmerged Commits: https://github.com/zulip/zulip/pull/12589/commits

    * **PR: [Cleaned and Rebased version of PR #10102 Multiple api keys #12511](https://github.com/zulip/zulip/pull/12511)**
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have mulitple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with mulitple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt alot about cherry picking, searching old commits, diffs practically.
    * In the second work period, merge conflicts again occured with my PR 12511. I had to rebase and fix new set of failing test. This experience gave me insights how a fast moving project can easily break previous unmerged work.
    * Unmerged Commits: https://github.com/zulip/zulip/pull/12511/commits

    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing and correcting Unit test because of buggy test endpoint. Intially wrote test using API endpoint that were used by similar tests already in the main codebase. But those pre existing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bug in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow principle of "Leave the code better than you found it"
    * Merged Commits: [d60f6c9](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49), [a98447b](https://github.com/zulip/zulip/commit/a98447b31200a815c331b02686a92a836393d06e),

    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged and Closed
    * Solves issue [#11956](https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.
    * Merged Commits: [1902f52](https://github.com/zulip/zulip/commit/1902f5210c41fc730e125dc03cbafd168e7d4e9d), []
  24. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 40 additions and 24 deletions.
    64 changes: 40 additions & 24 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,34 +1,50 @@
    ## PR I worked on
    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged and Closed
    * Solves issue [#11956](https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.
    ## PR I worked on
    * **PR: [search: Add is:public-stream to search entire history of public streams. #12999](https://github.com/zulip/zulip/pull/#12999)**
    * Status: Open and Reviewed once but spec got updated so making changes according to new specs. Original spec was complete and tested. New spec. is also close to completion.
    * Solves Issue [#8859](https://github.com/zulip/zulip/issue/8859).Right in zulip past message history can be searched in a single stream at a time. But This PR provides user ability to search all of the organisation's streams (both subscribed and unsubscribed) history at once, including messages from before user joint the organisation.
    * In zulip there are three streams, public, private, private with shared history. Initially spec. was to only allow search in public streams. I completed the work along with tests. Initially the syntax to search was `is:public-stream`. After review Tim suggested to expand it to public and private subscribed stream too. So now syntax is:
    * `streams:public` fetches all the history of public streams
    * `streams:subscribed` fetches all the history of subscribed streams public and private streams (which allows shared history) both
    Results for `streams:public` is same as `is:public-stream` The only difference is syntax. Work for `streams:public` is complete. Work for `streams:subscribed` remains. This feature I think completes a feature that is needed in a team chat software. Ablity to search whole orgnaisation message history will allow users to find information that have been shared already in past which might had been hidden in a unsubscibed stream within organisation.

    * **PR: [filter: Add more narrow filters that cannot mark messages as read. #12849](https://github.com/zulip/zulip/pull/12849)**
    * Status: Open and waiting for review.
    * Follow up based on [comment on PR #12747](https://github.com/zulip/zulip/pull/12747#issuecomment-510195186). Adds more narrows where message is not marked as read.
    * As a product decision, Team decided to expand more search views/narrows where message should not be marked as read. Eg. while searching for messages which has link using `has:link` operator or search messages where you were mentioned `is:mentioned` using operator. Most of time went into exhaustive tests so as to ensure everything is working. This feature have many possible cases. Exhaustive testing ensures that no issue crop up now and in future.

    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing and correcting Unit test because of buggy test endpoint. Intially wrote test using API endpoint that were used by similar tests already in the main codebase. But those pre existing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bug in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow principle of "Leave the code better than you found it"
    * **PR: [narrow: Fix to show last message in narrow when narrow allows.#12847](https://github.com/zulip/zulip/pull/12847)**
    * Status: Open and waiting for review (The code paths are complicated and need in depth review).
    * Solves a feature that was supposed to properly work in last PR. In PR [#12747](https://github.com/zulip/zulip/pull/12747) there was a feature not to show unread message first but show last message. All logic and functions were implemented and called but was UI was not updating. In initial manual testing the situation of showing unread message first was tested but showing last message was not tested when unread message were present. Also there was no automated test to check this situation so this problem gone unnoticed. . This PR basically fixes it and adds to test to ensure this kind of issue is caught in future. Lesson: Exhaustive automated test will ensure features working in future and present.

    * **PR: [Cleaned and Rebased version of PR #10102 Multiple api keys #12511](https://github.com/zulip/zulip/pull/12511)**
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have mulitple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with mulitple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt alot about cherry picking, searching old commits, diffs practically.
    * In the second work period, merge conflicts again occured with my PR 12511. I had to rebase and fix new set of failing test. This experience gave me insights how a fast moving project can easily break previous unmerged work.

    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * Status: Open and Work in progress due to some doubts in specs.
    * Solves issue [#12424](https://github.com/zulip/zulip/issues/12424)
    * A refactor prep. commits was merged [db3d81613bf0530db](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d)
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR still is stuck on that stage because I am still waiting for the doubts to be resolved.
    * **PR: [search: Don't mark messages as read in search narrow. #12747](https://github.com/zulip/zulip/pull/12747)**
    * Status: Merged and Closed.
    * Solves issue [#12556](https://github.com/zulip/zulip/issues/12556). Basic thing it solved was to not mark new unread messages as read when they appear in search query for an older conversation.
    * This was a pretty high priority and highly requested feature by community, both Tim and Yago were excited to see it happen. The main work was finding relevant places to make changes in existing codebase. Zulip's frontend is old and big, some places the code is too complicated so it was a time consuming process to read the existing code and figure out where to make changes. Every new feature required new code files and lines to be read. The actual logic was simple. After some experience, writing unit tests was also not that difficult.

    * **PR: [Fix searching and viewing Group PM and refactor of by_pm_with #12661](https://github.com/zulip/zulip/pull/12661)**
    * Status: Merged and Closed.
    * Solves issue [#12601](https://github.com/zulip/zulip/issues/12601) and [#12593](https://github.com/zulip/zulip/issues/12593)
    * Intially [#12593](https://github.com/zulip/zulip/issues/12593) seemed to be a backend bug but while Investigating bug lead to two completely different bugs. One was frontend bug (source was very hard to find) another as expected a backend one. [Investigation details](https://chat.zulip.org/#narrow/stream/9-issues/topic/.2312593.20DMs.20with.20deactivated.20users)
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of core data model of zulip the `Recipient` Model. I got chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.

    * **[PR: search: Don't mark messages as read in search narrow. #12747](https://github.com/zulip/zulip/pull/12747)**
    * Status: Merged and Closed.
    * Solves issue [#12556](https://github.com/zulip/zulip/issues/12556). Basic thing it solved was to not mark new unread messages as read when they appear in search query for an older conversation.
    * This was a pretty high priority and highly requested feature by community, both Tim and Yago were excited to see it happen. The main work was finding relevant places to make changes in existing codebase. Zulip's frontend is old and big, some places the code is too complicated so it was a time consuming process to read the existing code and figure out where to make changes. Every new feature required new code files and lines to be read. The actual logic was simple. After some experience, writing unit tests was also not that difficult.
    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * Status: Open and Work in progress due to some doubts in specs.
    * Solves issue [#12424](https://github.com/zulip/zulip/issues/12424)
    * A refactor prep. commits was merged [db3d81613bf0530db](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d)
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR still is stuck on that stage because I am still waiting for the doubts to be resolved.

    * **PR: [Cleaned and Rebased version of PR #10102 Multiple api keys #12511](https://github.com/zulip/zulip/pull/12511)**
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have mulitple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with mulitple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt alot about cherry picking, searching old commits, diffs practically.
    * In the second work period, merge conflicts again occured with my PR 12511. I had to rebase and fix new set of failing test. This experience gave me insights how a fast moving project can easily break previous unmerged work.

    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing and correcting Unit test because of buggy test endpoint. Intially wrote test using API endpoint that were used by similar tests already in the main codebase. But those pre existing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bug in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow principle of "Leave the code better than you found it"

    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged and Closed
    * Solves issue [#11956](https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.
  25. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -21,14 +21,14 @@
    * A refactor prep. commits was merged [db3d81613bf0530db](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d)
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR still is stuck on that stage because I am still waiting for the doubts to be resolved.

    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * **PR: [Fix searching and viewing Group PM and refactor of by_pm_with #12661](https://github.com/zulip/zulip/pull/12661)**
    * Status: Merged and Closed.
    * Solves issue [#12601](https://github.com/zulip/zulip/issues/12601) and [#12593](https://github.com/zulip/zulip/issues/12593)
    * Intially [#12593](https://github.com/zulip/zulip/issues/12593) seemed to be a backend bug but while Investigating bug lead to two completely different bugs. One was frontend bug (source was very hard to find) another as expected a backend one. [Investigation details](https://chat.zulip.org/#narrow/stream/9-issues/topic/.2312593.20DMs.20with.20deactivated.20users)
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of core data model of zulip the `Recipient` Model. I got chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.

    * **PR: search: Don't mark messages as read in search narrow. #12747**
    * **[PR: search: Don't mark messages as read in search narrow. #12747](https://github.com/zulip/zulip/pull/12747)**
    * Status: Merged and Closed.
    * Solves issue [#12556](). Basic thing it solved was to not mark new unread messages as read when they appear in search query for an older conversation.
    * Solves issue [#12556](https://github.com/zulip/zulip/issues/12556). Basic thing it solved was to not mark new unread messages as read when they appear in search query for an older conversation.
    * This was a pretty high priority and highly requested feature by community, both Tim and Yago were excited to see it happen. The main work was finding relevant places to make changes in existing codebase. Zulip's frontend is old and big, some places the code is too complicated so it was a time consuming process to read the existing code and figure out where to make changes. Every new feature required new code files and lines to be read. The actual logic was simple. After some experience, writing unit tests was also not that difficult.

  26. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 28 additions and 9 deletions.
    37 changes: 28 additions & 9 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,15 +1,34 @@
    ## PR I worked on
    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged
    * Solves issue (https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time.
    * Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch.
    * Status: Merged and Closed
    * Solves issue [#11956](https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time. Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch. This PR gave me experence to simulate conditions in test codes.

    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged
    * Solves issue (https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing Unit test because of buggy test endpoint. But ultimately issue was identified and I was able to complete the test
    * Status: Merged and Closed
    * Solves issue [#12310](https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing and correcting Unit test because of buggy test endpoint. Intially wrote test using API endpoint that were used by similar tests already in the main codebase. But those pre existing code were buggy. I fixed those tests in commit [d024c30cd8baf](https://github.com/zulip/zulip/commit/d60f6c9ad97b6cd8a6cb48637dea33045a949f49). Later wrote correct tests for issue #12383. This experience taught me valid pre existing codebase or tests can have bug in them. Always lookout for code around you and investigate any weird exiting code even if it's not directly related to your current work. Try to follow principle of "Leave the code better than you found it"

    ###Cleaned and Rebased version of PR #10102 Multiple api keys #12511
    * **PR: [Cleaned and Rebased version of PR #10102 Multiple api keys #12511](https://github.com/zulip/zulip/pull/12511)**
    * Status: Open and Waiting for review
    * Solves merge conflicts, rebasing and cleaning of PR [#10102](https://github.com/zulip/zulip/pull/10102)
    * PR #10102 was started by my mentor, Yago during his GSoC 2018 work. I had to solve merge conflicts and rebase it with latest master. This PR basically allows user to have mulitple api keys. As of time of writing, a Zulip user have a single regenratable API key. In original PR cache deletion of API key was not there but a cache deletion logic for single key had been added in codebase by Tim Abbott I extended that cache deletion of api key to work with mulitple api key model ( ee https://github.com/zulip/zulip/pull/12511/files#r291530222) In this process I learnt more about cache codebase of zulip. This PR improved my git skills and I learnt alot about cherry picking, searching old commits, diffs practically.
    * In the second work period, merge conflicts again occured with my PR 12511. I had to rebase and fix new set of failing test. This experience gave me insights how a fast moving project can easily break previous unmerged work.

    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * Status: Open and Work in progress due to some doubts in specs.
    * Solves issue [#12424](https://github.com/zulip/zulip/issues/12424)
    * A refactor prep. commits was merged [db3d81613bf0530db](https://github.com/zulip/zulip/commit/db3d81613bf0530db8126e6b6aee1e095cb4109d)
    * Ability to create bot with admin privileges by an admin is done (and checks to prevent non admin to do so). Also updated tests to check some side cases mentioned in [comment](https://github.com/zulip/zulip/issues/12424#issue-449479222). The only stuff that is missing is to add constraints what admin bot can't do but only humans can do. I first manually audited the whole codebase to find existing admin capabilities and human only capabilities ( see [conversation](https://chat.zulip.org/#narrow/stream/9-issues/topic/Admin.20Bot.20.20.5B.2312424.5D/near/754353) ) Tim and Rishi discussed what to add and what not to. I started working on the given specs but later I switched to another work due to some [doubts](https://github.com/zulip/zulip/pull/12589#issuecomment-508886755) in specification of admin bots. The PR still is stuck on that stage because I am still waiting for the doubts to be resolved.

    * **PR: [ WIP Administrator Bot #12589](https://github.com/zulip/zulip/pull/12589)**
    * Status: Merged and Closed.
    * Solves issue [#12601](https://github.com/zulip/zulip/issues/12601) and [#12593](https://github.com/zulip/zulip/issues/12593)
    * Intially [#12593](https://github.com/zulip/zulip/issues/12593) seemed to be a backend bug but while Investigating bug lead to two completely different bugs. One was frontend bug (source was very hard to find) another as expected a backend one. [Investigation details](https://chat.zulip.org/#narrow/stream/9-issues/topic/.2312593.20DMs.20with.20deactivated.20users)
    * The fix for bug and another refactor work [#12601](https://github.com/zulip/zulip/issues/12601) overlapped so I solved both in single PR in three commits. The refactor experience took me to one of core data model of zulip the `Recipient` Model. I got chance to understand how db schema and sqlalchemy db queries works. I also learnt how to write clean code while doing the refactor.

    * **PR: search: Don't mark messages as read in search narrow. #12747**
    * Status: Merged and Closed.
    * Solves issue [#12556](). Basic thing it solved was to not mark new unread messages as read when they appear in search query for an older conversation.
    * This was a pretty high priority and highly requested feature by community, both Tim and Yago were excited to see it happen. The main work was finding relevant places to make changes in existing codebase. Zulip's frontend is old and big, some places the code is too complicated so it was a time consuming process to read the existing code and figure out where to make changes. Every new feature required new code files and lines to be read. The actual logic was simple. After some experience, writing unit tests was also not that difficult.

    ##[WIP ] Administrator Bot #12589
  27. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 9 additions and 2 deletions.
    11 changes: 9 additions & 2 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,14 @@
    ## Community bonding and Week 1
    ## PR I worked on
    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**
    * Status: Merged
    * Solves issue (https://github.com/zulip/zulip/issues/11956) of production server holding hundreds of locks at the same time. Frontend UIs may attempt to mark 10,000s of messages and query for flagging message in backend could run for extremely long periods of time (e.g. 72478s in one instance!).
    * Solution implemented is to make webapp batch the message flagging requests to at most ~1K message IDs at a time.
    * Most of the work went into writing frontend unit tests to ensure that feature is working correctly. I figured out a way to intercept the request in javascript and ensured that only list of id of length equal to batch size is being sent as request payload. I mocked server response and mark messages in UI and ensure already flagged message ids are not being sent in the next batch.

    ### bots: Bots can post to announcement-only streams if their owner can. #12383
    * **PR: [bots: Bots can post to announcement-only streams if their owner can. #12383](https://github.com/zulip/zulip/pull/12383/)**
    * Status: Merged
    * Solves issue (https://github.com/zulip/zulip/issues/12310)
    * Most of time went into writing Unit test because of buggy test endpoint. But ultimately issue was identified and I was able to complete the test

    ###Cleaned and Rebased version of PR #10102 Multiple api keys #12511

  28. thedeveloperr revised this gist Aug 20, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@
    ## Community bonding and Week 1
    ### PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)
    * **PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)**

    ### bots: Bots can post to announcement-only streams if their owner can. #12383

  29. thedeveloperr created this gist Aug 20, 2019.
    8 changes: 8 additions & 0 deletions workproduct.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,8 @@
    ## Community bonding and Week 1
    ### PR: [Batch read flag requests to at most 1k message IDs #12264](https://github.com/zulip/zulip/pull/12264)

    ### bots: Bots can post to announcement-only streams if their owner can. #12383

    ###Cleaned and Rebased version of PR #10102 Multiple api keys #12511

    ##[WIP ] Administrator Bot #12589