Hi all--
The Squeak board is trying an experiment. We've created the GitHub repo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Please bring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board
[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Hi Craig, dear board, dear all,
wow, I seem to be a bit late on the party, but nevertheless, I wanted to share some thoughts about this - I have been advocating for GitHub issues for a longer time already, and I'm really excited to see some progress here. Thanks!
I have quite a few ideas, trying to be as brief as possible:
1. Connection to mailing list
As mentioned by others already, advantages of the ML include a high reach within the community and (basic) independency of other platforms (at least, all posts will be preserved in our archives). I would strongly opt for setting up the equivalent of OpenSmalltalk Bot [1] for the new issue tracker, too. Three questions:
i. Who are the developers/maintainers of this bot? Would you mind open-sourcing the scripts/infrastructure for it? If it is a simple process, I would volunteer to try my luck if no one else is available. Maybe we could just extend the scope of the existing bot? ii. What are the current limitations of the bot? I think metadata such as labels/assignees will not be reported to the mailing list, but we might renounce that. Ideally, there will be a repository to which everyone interested could contribute in order to improve i.e. the formatting of bot messages. iii. If the issue tracker will be used more frequently, I can put integration of GitHub Issues to the backlog of Squeak Inbox Talk (volunteers would also be welcome, of course!). This might be a helpful combination.
2. Design of the issue tracker
I'm glad that a first step has been taken, but my personal demands on the appearance of the issue tracker would still be higher. Some proposals:
i. Could we please rename this repo to just "squeak-issues" or "squeak-image"? I understand the idea behind the title "object-memory", but IMHO it is a bit too abstract - when I stumbled upon the repo for the first time, I would rather have expected a VM component or something like that. Our goal should be the easiest recognizability that is possible. ii. I would volunteer to extend the repo structure with a few labels, issue templates, a nicer readme, etc. Also, I could try to maintain the issue list a bit (assigning labels, closing issues etc.). However, all of this requires write access to the repository - would it be possible to grant write access to all (interested) core developers? Of course, we can discuss any proposals for a labeling scheme or issue templates before. iii. Do we need any guidelines/etiquette for the issue tracker, for instance with regard to relevance or closing reasons for issues? I might be not the only person to have dozens of bug reports, feature requests, etc. lying on my desktop. Would it be helpful to copy all of them to the new issue tracker or should we restrain ourselves by some criteria? (What I would dislike is something like auto-closing of issues older than x days. IMO this not much more than a PR trick for organizations that have lost overview of their issues, and it is very discouraging to bug reporters.) iv. Are we also intending to task planning features of GitHub (such as milestones, assignees, projects)?
3. Notes
- As the question has arisen about individual email notifications: If you have a GitHub account, you can watch all activities on the repository via the Watch button in the upper right corner. You can also subscribe to individual conversations via the notifications widget in the right sidebar of any issue. You don't need GitHub Actions for this. However, I do not think that this is an alternative to a mailing list connection for everyone - we should really try to merge all artifacts into a single place. - I also like the new "Send feedback" item in the help menu. How would you think about improving automation for this? We could try to build a mix between Squot's feedback dialog and the solution I built for Squeak Inbox Talk. Ideally, everyone could file their feedback without leaving their image or creating a GitHub account, and each feedback could contain the basic environment data automatically.
Looking forward to your replies! Have a nice weekend! :-)
Best, Christoph
[1] https://github.com/OpenSmalltalk-Bot
--- Sent from Squeak Inbox Talk
On 2022-03-01T21:21:53-08:00, craig@blackpagedigital.com wrote:
Hi all--
The Squeak board is trying an experiment. We've created the GitHubrepo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Pleasebring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Hi Christoph --
Thanks for sharing you thoughts. Let's see how this new method of issue tracking gets accepted. Then we can surely also talk about integration into squeak-dev.
Keep it simple and agile. :-)
Best, Marcel Am 02.04.2022 00:25:02 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi Craig, dear board, dear all,
wow, I seem to be a bit late on the party, but nevertheless, I wanted to share some thoughts about this - I have been advocating for GitHub issues for a longer time already, and I'm really excited to see some progress here. Thanks!
I have quite a few ideas, trying to be as brief as possible:
1. Connection to mailing list
As mentioned by others already, advantages of the ML include a high reach within the community and (basic) independency of other platforms (at least, all posts will be preserved in our archives). I would strongly opt for setting up the equivalent of OpenSmalltalk Bot [1] [https://github.com/OpenSmalltalk-Bot] for the new issue tracker, too. Three questions:
i. Who are the developers/maintainers of this bot? Would you mind open-sourcing the scripts/infrastructure for it? If it is a simple process, I would volunteer to try my luck if no one else is available. Maybe we could just extend the scope of the existing bot? ii. What are the current limitations of the bot? I think metadata such as labels/assignees will not be reported to the mailing list, but we might renounce that. Ideally, there will be a repository to which everyone interested could contribute in order to improve i.e. the formatting of bot messages. iii. If the issue tracker will be used more frequently, I can put integration of GitHub Issues to the backlog of Squeak Inbox Talk (volunteers would also be welcome, of course!). This might be a helpful combination.
2. Design of the issue tracker
I'm glad that a first step has been taken, but my personal demands on the appearance of the issue tracker would still be higher. Some proposals:
i. Could we please rename this repo to just "squeak-issues" or "squeak-image"? I understand the idea behind the title "object-memory", but IMHO it is a bit too abstract - when I stumbled upon the repo for the first time, I would rather have expected a VM component or something like that. Our goal should be the easiest recognizability that is possible. ii. I would volunteer to extend the repo structure with a few labels, issue templates, a nicer readme, etc. Also, I could try to maintain the issue list a bit (assigning labels, closing issues etc.). However, all of this requires write access to the repository - would it be possible to grant write access to all (interested) core developers? Of course, we can discuss any proposals for a labeling scheme or issue templates before. iii. Do we need any guidelines/etiquette for the issue tracker, for instance with regard to relevance or closing reasons for issues? I might be not the only person to have dozens of bug reports, feature requests, etc. lying on my desktop. Would it be helpful to copy all of them to the new issue tracker or should we restrain ourselves by some criteria? (What I would dislike is something like auto-closing of issues older than x days. IMO this not much more than a PR trick for organizations that have lost overview of their issues, and it is very discouraging to bug reporters.) iv. Are we also intending to task planning features of GitHub (such as milestones, assignees, projects)?
3. Notes
- As the question has arisen about individual email notifications: If you have a GitHub account, you can watch all activities on the repository via the Watch button in the upper right corner. You can also subscribe to individual conversations via the notifications widget in the right sidebar of any issue. You don't need GitHub Actions for this. However, I do not think that this is an alternative to a mailing list connection for everyone - we should really try to merge all artifacts into a single place. - I also like the new "Send feedback" item in the help menu. How would you think about improving automation for this? We could try to build a mix between Squot's feedback dialog and the solution I built for Squeak Inbox Talk. Ideally, everyone could file their feedback without leaving their image or creating a GitHub account, and each feedback could contain the basic environment data automatically.
Looking forward to your replies! Have a nice weekend! :-)
Best, Christoph
[1] https://github.com/OpenSmalltalk-Bot [https://github.com/OpenSmalltalk-Bot]
--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
On 2022-03-01T21:21:53-08:00, craig@blackpagedigital.com wrote:
Hi all--
The Squeak board is trying an experiment. We've created the GitHub repo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Please bring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board
[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Hi all,
I would like to kindly bump this thread, as I still stand to every single proposal that I have made. I think the issue tracker has been accepted pretty well with over 100 posts in total [1]. In particular, I am concerned by the new dependency on GitHub (we don't mirror the issues), community fragmentation (only few people seem to receive issues), and the repo name (which is still very misleading to newcomers).
Regarding Jakob's concern about labels: First, we could give way more people access to labels (but at least the board + all core developers). Alternatively, we could use issue templates (but they are static) or a GHA-based bot that anyone can instruct to assign labels (/addlabel base system, /removelabel bug, etc.).
Looking forward to your replies!
Best, Christoph
[1] 140 posts: client := WebClient new. response := client token: token; httpGet: 'https://api.github.com/repos/squeak-smalltalk/squeak-object-memory', '/issues?per_page=100' do: [:request | request contentType: 'application/vnd.github.v3+json'. request headerAt: 'Authorization' put: 'token ' , client token]. issues := Json readFrom: response content readStream. issues size + (issues detectSum: #comments)
--- Sent from Squeak Inbox Talk
On 2022-04-02T00:24:49+02:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Craig, dear board, dear all,
wow, I seem to be a bit late on the party, but nevertheless, I wanted to share some thoughts about this - I have been advocating for GitHub issues for a longer time already, and I'm really excited to see some progress here. Thanks!
I have quite a few ideas, trying to be as brief as possible:
- Connection to mailing list
As mentioned by others already, advantages of the ML include a high reach within the community and (basic) independency of other platforms (at least, all posts will be preserved in our archives). I would strongly opt for setting up the equivalent of OpenSmalltalk Bot [1] for the new issue tracker, too. Three questions:
i. Who are the developers/maintainers of this bot? Would you mind open-sourcing the scripts/infrastructure for it? If it is a simple process, I would volunteer to try my luck if no one else is available. Maybe we could just extend the scope of the existing bot? ii. What are the current limitations of the bot? I think metadata such as labels/assignees will not be reported to the mailing list, but we might renounce that. Ideally, there will be a repository to which everyone interested could contribute in order to improve i.e. the formatting of bot messages. iii. If the issue tracker will be used more frequently, I can put integration of GitHub Issues to the backlog of Squeak Inbox Talk (volunteers would also be welcome, of course!). This might be a helpful combination.
- Design of the issue tracker
I'm glad that a first step has been taken, but my personal demands on the appearance of the issue tracker would still be higher. Some proposals:
i. Could we please rename this repo to just "squeak-issues" or "squeak-image"? I understand the idea behind the title "object-memory", but IMHO it is a bit too abstract - when I stumbled upon the repo for the first time, I would rather have expected a VM component or something like that. Our goal should be the easiest recognizability that is possible. ii. I would volunteer to extend the repo structure with a few labels, issue templates, a nicer readme, etc. Also, I could try to maintain the issue list a bit (assigning labels, closing issues etc.). However, all of this requires write access to the repository - would it be possible to grant write access to all (interested) core developers? Of course, we can discuss any proposals for a labeling scheme or issue templates before. iii. Do we need any guidelines/etiquette for the issue tracker, for instance with regard to relevance or closing reasons for issues? I might be not the only person to have dozens of bug reports, feature requests, etc. lying on my desktop. Would it be helpful to copy all of them to the new issue tracker or should we restrain ourselves by some criteria? (What I would dislike is something like auto-closing of issues older than x days. IMO this not much more than a PR trick for organizations that have lost overview of their issues, and it is very discouraging to bug reporters.) iv. Are we also intending to task planning features of GitHub (such as milestones, assignees, projects)?
- Notes
- As the question has arisen about individual email notifications: If you have a GitHub account, you can watch all activities on the repository via the Watch button in the upper right corner. You can also subscribe to individual conversations via the notifications widget in the right sidebar of any issue. You don't need GitHub Actions for this. However, I do not think that this is an alternative to a mailing list connection for everyone - we should really try to merge all artifacts into a single place.
- I also like the new "Send feedback" item in the help menu. How would you think about improving automation for this? We could try to build a mix between Squot's feedback dialog and the solution I built for Squeak Inbox Talk. Ideally, everyone could file their feedback without leaving their image or creating a GitHub account, and each feedback could contain the basic environment data automatically.
Looking forward to your replies! Have a nice weekend! :-)
Best, Christoph
[1] https://github.com/OpenSmalltalk-Bot
Sent from Squeak Inbox Talk
On 2022-03-01T21:21:53-08:00, craig at blackpagedigital.com wrote:
Hi all--
The Squeak board is trying an experiment. We've created the GitHub repo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Please bring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board
[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Hi --
I expanded the "Core" team in our GitHub "squeak-smalltalk" organization. That team can now "Triage" in the "squeak-object-memory" repository.
Also the "Board" team can now "Maintain" in the repo "squeak-object-memory".
Please do not modify the kind of tags we currently have. Just add/remove them to/from issues as you see fit.
Please let me know if there are further issues.
Best, Marcel
P.S.: I like the name "squeak-object-memory" :-D
Am 17.08.2023 10:34:07 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi all,
I would like to kindly bump this thread, as I still stand to every single proposal that I have made. I think the issue tracker has been accepted pretty well with over 100 posts in total [1]. In particular, I am concerned by the new dependency on GitHub (we don't mirror the issues), community fragmentation (only few people seem to receive issues), and the repo name (which is still very misleading to newcomers).
Regarding Jakob's concern about labels: First, we could give way more people access to labels (but at least the board + all core developers). Alternatively, we could use issue templates (but they are static) or a GHA-based bot that anyone can instruct to assign labels (/addlabel base system, /removelabel bug, etc.).
Looking forward to your replies!
Best, Christoph
[1] 140 posts: client := WebClient new. response := client token: token; httpGet: 'https://api.github.com/repos/squeak-smalltalk/squeak-object-memory', '/issues?per_page=100' do: [:request | request contentType: 'application/vnd.github.v3+json'. request headerAt: 'Authorization' put: 'token ' , client token]. issues := Json readFrom: response content readStream. issues size + (issues detectSum: #comments)
--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
On 2022-04-02T00:24:49+02:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Craig, dear board, dear all,
wow, I seem to be a bit late on the party, but nevertheless, I wanted to share some thoughts about this - I have been advocating for GitHub issues for a longer time already, and I'm really excited to see some progress here. Thanks!
I have quite a few ideas, trying to be as brief as possible:
- Connection to mailing list
As mentioned by others already, advantages of the ML include a high reach within the community and (basic) independency of other platforms (at least, all posts will be preserved in our archives). I would strongly opt for setting up the equivalent of OpenSmalltalk Bot [1] for the new issue tracker, too. Three questions:
i. Who are the developers/maintainers of this bot? Would you mind open-sourcing the scripts/infrastructure for it? If it is a simple process, I would volunteer to try my luck if no one else is available. Maybe we could just extend the scope of the existing bot? ii. What are the current limitations of the bot? I think metadata such as labels/assignees will not be reported to the mailing list, but we might renounce that. Ideally, there will be a repository to which everyone interested could contribute in order to improve i.e. the formatting of bot messages. iii. If the issue tracker will be used more frequently, I can put integration of GitHub Issues to the backlog of Squeak Inbox Talk (volunteers would also be welcome, of course!). This might be a helpful combination.
- Design of the issue tracker
I'm glad that a first step has been taken, but my personal demands on the appearance of the issue tracker would still be higher. Some proposals:
i. Could we please rename this repo to just "squeak-issues" or "squeak-image"? I understand the idea behind the title "object-memory", but IMHO it is a bit too abstract - when I stumbled upon the repo for the first time, I would rather have expected a VM component or something like that. Our goal should be the easiest recognizability that is possible. ii. I would volunteer to extend the repo structure with a few labels, issue templates, a nicer readme, etc. Also, I could try to maintain the issue list a bit (assigning labels, closing issues etc.). However, all of this requires write access to the repository - would it be possible to grant write access to all (interested) core developers? Of course, we can discuss any proposals for a labeling scheme or issue templates before. iii. Do we need any guidelines/etiquette for the issue tracker, for instance with regard to relevance or closing reasons for issues? I might be not the only person to have dozens of bug reports, feature requests, etc. lying on my desktop. Would it be helpful to copy all of them to the new issue tracker or should we restrain ourselves by some criteria? (What I would dislike is something like auto-closing of issues older than x days. IMO this not much more than a PR trick for organizations that have lost overview of their issues, and it is very discouraging to bug reporters.) iv. Are we also intending to task planning features of GitHub (such as milestones, assignees, projects)?
- Notes
- As the question has arisen about individual email notifications: If you have a GitHub account, you can watch all activities on the repository via the Watch button in the upper right corner. You can also subscribe to individual conversations via the notifications widget in the right sidebar of any issue. You don't need GitHub Actions for this. However, I do not think that this is an alternative to a mailing list connection for everyone - we should really try to merge all artifacts into a single place.
- I also like the new "Send feedback" item in the help menu. How would you think about improving automation for this? We could try to build a mix between Squot's feedback dialog and the solution I built for Squeak Inbox Talk. Ideally, everyone could file their feedback without leaving their image or creating a GitHub account, and each feedback could contain the basic environment data automatically.
Looking forward to your replies! Have a nice weekend! :-)
Best, Christoph
[1] https://github.com/OpenSmalltalk-Bot
Sent from Squeak Inbox Talk
On 2022-03-01T21:21:53-08:00, craig at blackpagedigital.com wrote:
Hi all--
The Squeak board is trying an experiment. We've created the GitHub repo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Please bring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board
[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Hi,
Am Do., 17. Aug. 2023 um 10:33 Uhr schrieb < christoph.thiede@student.hpi.uni-potsdam.de>:
I am concerned by [...] the repo name (which is still very misleading to newcomers).
Renaming it would cause some effort (at least to update links), and I am not sure whether it is worth it at this point. That aside, I could imagine just calling it "squeak". (As in: https://github.com/squeak-smalltalk/squeak) If we ever have a mirror of the trunk source code on GitHub, we should put it in this repository so that the issues are close to it.
squeak-object-memory: I understand where it comes from and it is technically accurate. But sounds quite technical, named with a VM perspective on the matter. squeak-image: sounds more familiar, but is less accurate since this is not (only) about snapshots. squeak-issues: the most accurate for the current use, but would need another rename if we ever start putting something relevant into the repository.
Kind regards, Jakob
Hi all --
I think that both "https://bugs.squeak.org" and the readme.md a very clear for newcomers. I see no need to optimize name lookup from within other GitHub projects or contexts.
At this point, the tool "GitHub repo issues" is just practical for managing Squeak issues. It should not indicate that we plan to move project development entirely to GitHub or anything similar.
We should be very careful with interpreting "too much" into the fact that we manage Squeak's issues through GitHub at this point. When talking to newcomers, these are the entry points:
https://www.squeak.org/ https://source.squeak.org/
...
No mentioning of GitHub or that helper repository. It's just an implementation detail. And not worth renaming at this point.
Best, Marcel
Am 17.08.2023 15:26:33 schrieb Jakob Reschke jakres+squeak@gmail.com: Hi,
Am Do., 17. Aug. 2023 um 10:33 Uhr schrieb <christoph.thiede@student.hpi.uni-potsdam.de [mailto:christoph.thiede@student.hpi.uni-potsdam.de]>:
I am concerned by [...] the repo name (which is still very misleading to newcomers).
Renaming it would cause some effort (at least to update links), and I am not sure whether it is worth it at this point. That aside, I could imagine just calling it "squeak". (As in: https://github.com/squeak-smalltalk/squeak [https://github.com/squeak-smalltalk/squeak]) If we ever have a mirror of the trunk source code on GitHub, we should put it in this repository so that the issues are close to it.
squeak-object-memory: I understand where it comes from and it is technically accurate. But sounds quite technical, named with a VM perspective on the matter. squeak-image: sounds more familiar, but is less accurate since this is not (only) about snapshots. squeak-issues: the most accurate for the current use, but would need another rename if we ever start putting something relevant into the repository.
Kind regards, Jakob
My attempts to implement ELib's Far Promises, calls this Scope. In Hymn I am calling this interface the Oasis, the Naming System and locality.
HTH, rabbit
On 8/17/23 09:26, Jakob Reschke wrote:
Hi,
Am Do., 17. Aug. 2023 um 10:33 Uhr schrieb christoph.thiede@student.hpi.uni-potsdam.de:
I am concerned by [...] the repo name (which is still very misleading to newcomers).
Renaming it would cause some effort (at least to update links), and I am not sure whether it is worth it at this point. That aside, I could imagine just calling it "squeak". (As in: https://github.com/squeak-smalltalk/squeak) If we ever have a mirror of the trunk source code on GitHub, we should put it in this repository so that the issues are close to it.
squeak-object-memory: I understand where it comes from and it is technically accurate. But sounds quite technical, named with a VM perspective on the matter. squeak-image: sounds more familiar, but is less accurate since this is not (only) about snapshots. squeak-issues: the most accurate for the current use, but would need another rename if we ever start putting something relevant into the repository.
Kind regards, Jakob
-- ••• rabbit ❤️🔥🐰
My apologies, I meant to add the Scope keeps the remote-object-memory tables.
On 8/17/23 09:56, rabbit wrote:
My attempts to implement ELib's Far Promises, calls this Scope. In Hymn I am calling this interface the Oasis, the Naming System and locality.
HTH, rabbit
On 8/17/23 09:26, Jakob Reschke wrote:
Hi,
Am Do., 17. Aug. 2023 um 10:33 Uhr schrieb christoph.thiede@student.hpi.uni-potsdam.de:
I am concerned by [...] the repo name (which is still very misleading to newcomers).
Renaming it would cause some effort (at least to update links), and I am not sure whether it is worth it at this point. That aside, I could imagine just calling it "squeak". (As in: https://github.com/squeak-smalltalk/squeak) If we ever have a mirror of the trunk source code on GitHub, we should put it in this repository so that the issues are close to it.
squeak-object-memory: I understand where it comes from and it is technically accurate. But sounds quite technical, named with a VM perspective on the matter. squeak-image: sounds more familiar, but is less accurate since this is not (only) about snapshots. squeak-issues: the most accurate for the current use, but would need another rename if we ever start putting something relevant into the repository.
Kind regards, Jakob
-- ••• rabbit ❤️🔥🐰
-- ••• rabbit ❤️🔥🐰
Hi all --
Issue tags are now live. The readme.md was updated to document the process:
https://github.com/squeak-smalltalk/squeak-object-memory
https://github.com/squeak-smalltalk/squeak-object-memory/labels
Best, Marcel Am 02.03.2022 06:22:13 schrieb Craig Latta craig@blackpagedigital.com:
Hi all--
The Squeak board is trying an experiment. We've created the GitHub repo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Please bring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board
[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Hi Marcel,
Thank you for the added organization!
Are you aware that regular users cannot assign labels to issues? In that regard, the section in the readme may benefit from a note that one does not read this to do it correctly, but rather to understand how the "maintainers" are categorizing issues. Or point out that these instructions are for maintainers. Otherwise some may feel disappointed that they have just learned this -- to do everything right -- and now cannot even use it. ;-)
I suppose you have to be a member of the squeak-smalltalk organization to be able to assign labels.
Kind regards, Jakob
Am Mo., 18. Apr. 2022 um 13:35 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
Issue tags are now live. The readme.md was updated to document the process:
https://github.com/squeak-smalltalk/squeak-object-memory https://github.com/squeak-smalltalk/squeak-object-memory/labels
Best, Marcel
Am 02.03.2022 06:22:13 schrieb Craig Latta craig@blackpagedigital.com:
Hi all--
The Squeak board is trying an experiment. We've created the GitHub repo "squeak-object-memory", and are curious to see how useful it is to track issues there.
With this message, I can close the first issue[1]. :) Please bring on the other thirty gazillion of them...
thanks! Craig, on behalf of the Squeak board
[1] https://github.com/squeak-smalltalk/squeak-object-memory/issues/1
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
squeak-dev@lists.squeakfoundation.org
-
christoph.thiede＠student.hpi.uni-potsdam.de -
Craig Latta -
Jakob Reschke -
Marcel Taeumel -
rabbit