Writing all kinds of documentation, inside and outside the image is a very important and much appreciated contribution. On 04 Aug 2014, at 22:37, kilon alios <kilon.alios@gmail.com> wrote:

I can tell you why. Because its rarely is simple for people not familiar with Pharo like me.

I once tried to help Damien with PharoLauncher. I added the progress bars you get when you download a new image it was simple as pie. Then Damien recommended for me to try to add support to PharoLauncher for CLI . I understand how Pharo does CLI stuff but was not able to understand anything about how PharoLauncher downloads and handles images. I literally spent hours trying to understand the internal architecture and gave up after 2 hours or so cause I had no clue how things worked.

Also finding a bug to fix in Pharo is time consuming, you have to go through one bug after another till you find that you can figure out whats wrong and how to fix. Its not easy and its very annoying at times.

Generally what kills me is lack of motivation, I don't like reading other's people code, I don't even like reading my code. I prefer documentation , If I am to fix a bug I want at least someone to show me how it works because figuring it by myself takes a lot of time and I am simply not willing to invest that time just because people find documentation something that should write one day when their software reaches version 1 meaning years later.

So you want to motivate people to contribute to bug fixes ? Do not allow any code to enter pharo main distribution without full class comments. I really mean "full class comment" not 2 , or 3 lines.

PBE has been left hanging years after the release of 1.4 , why ? you expect people to contribute to bug fixes even when the most basic of documentation is abandoned ?

Sorry if I sound harsh but you wanted a honest answer . For me undocumented code is far more annoying than a bug or a missing feature.

On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo@free.fr> wrote: Hi guys

I'm sure that most of you did not realize it, but Pharo does not magically improve. It improves because some of us are looking at the tracker issues and looking at the code and improving it.

Since Pharo is yours I wonder why you do not take the time to improve. In fact, this is the key advantage of true open-source: being able to have an impact. An example, I was fed up to have a stupid widget to move method between protocol and classes between packages. I fixed it. It took my 20 min without knowing anything about Nautilus.

And it improved Pharo Right now, Right there. Of course if more people would be improving Pharo we could also focus on enabling technology and frameworks. But apparently we have to choose either we improve Pharo now or we invent cool stuff that takes time. I wonder why I do not go for the fame of writing a cool stuff instead of just improving systematically the system.

I wrote some roadmaps for people willing also to help.

https://github.com/pharo-project/pharo-workingRoadmaps

Stef

I don't question people contribution to Pharo. I do think however that we need to prioritize documentation. For example Blender development works in a way that a developers adding a feature to Blender main repo (not external code and external libraries) must add documentation to Blender wiki for the users. Also Blender has coding guidelines that need to be followed in order for code to added to main repo, does Pharo has something similar ? If yes where is such a document ? Also Blender mailing list is very active with major bug fixes and features enhancement , in Pharo it looks to me that a lot of this discussion is located to fogbug . That means however than unless you frequent there its very difficult to track changes that affect your workflow. Not just Blender but many open source projects work similarly. On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess@web.de> wrote:

2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios@gmail.com>:

I can tell you why. Because its rarely is simple for people not familiar

...

with Pharo like me.

I once tried to help Damien with PharoLauncher. I added the progress bars you get when you download a new image it was simple as pie. Then Damien recommended for me to try to add support to PharoLauncher for CLI . I understand how Pharo does CLI stuff but was not able to understand anything about how PharoLauncher downloads and handles images. I literally spent hours trying to understand the internal architecture and gave up after 2 hours or so cause I had no clue how things worked.

Also finding a bug to fix in Pharo is time consuming, you have to go through one bug after another till you find that you can figure out whats wrong and how to fix. Its not easy and its very annoying at times.

Generally what kills me is lack of motivation, I don't like reading other's people code, I don't even like reading my code. I prefer documentation , If I am to fix a bug I want at least someone to show me how it works because figuring it by myself takes a lot of time and I am simply not willing to invest that time just because people find documentation something that should write one day when their software reaches version 1 meaning years later.

So you want to motivate people to contribute to bug fixes ? Do not allow any code to enter pharo main distribution without full class comments. I really mean "full class comment" not 2 , or 3 lines.

PBE has been left hanging years after the release of 1.4 , why ? you expect people to contribute to bug fixes even when the most basic of documentation is abandoned ?

Sorry if I sound harsh but you wanted a honest answer . For me undocumented code is far more annoying than a bug or a missing feature.

I find it a bit to harsh :) +1 for more source code documentation, but keep in mind that there are people that may not do proper documentation (even change code or fix bugs and don't document their code) but doing A LOT for pharo behind the scenes.

...

On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo@free.fr> wrote:

...

Hi guys

I'm sure that most of you did not realize it, but Pharo does not magically improve. It improves because some of us are looking at the tracker issues and looking at the code and improving it.

Since Pharo is yours I wonder why you do not take the time to improve. In fact, this is the key advantage of true open-source: being able to have an impact. An example, I was fed up to have a stupid widget to move method between protocol and classes between packages. I fixed it. It took my 20 min without knowing anything about Nautilus.

And it improved Pharo Right now, Right there. Of course if more people would be improving Pharo we could also focus on enabling technology and frameworks. But apparently we have to choose either we improve Pharo now or we invent cool stuff that takes time. I wonder why I do not go for the fame of writing a cool stuff instead of just improving systematically the system.

I wrote some roadmaps for people willing also to help.

https://github.com/pharo-project/pharo-workingRoadmaps

Stef

I hate that there is no wiki. And the Squeak wiki is still useful to find out how some things do work internally. Phil On Tue, Aug 5, 2014 at 11:20 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 05 Aug 2014, at 11:05, kilon alios <kilon.alios@gmail.com> wrote:

I don't question people contribution to Pharo.

I do think however that we need to prioritize documentation. For example Blender development works in a way that a developers adding a feature to Blender main repo (not external code and external libraries) must add documentation to Blender wiki for the users.

+1 we do not like wikis (bah, I like them, but others don’t… and they have a point: a wiki must be maintained, otherwise is a waist of time and effort). but… since Pharo4 we started a practice which is: we do not integrate any new stuff that is not correctly commented (in classes), with tests and (if possible), examples.

in the long way this is the best because Pharo relies a lot in “autodocumentation”.

now, we can improve this: - even if new stuff has to come that way, most of the code inside image is poorly documented, tested and examples. We can improve that. We need to. I remember the comment per day Luc started a couple of years ago… is complicated to have them running in long way (until documentation is finished) because people get tired, but we could have a “two weeks comments” each three months or something like that. Not perfect, but better than what we have now. - I dream with PetitParser integrated into Pharo, and then a markdown/pillar parser into class comments, allowing us to have better formating and references, etc. to improve navigation.

and of course, more can be done: -tutorials for newbies (your work on the videos is great there, btw!) -example projects in different areas (I think the laser game is a good one, but we need more “professional” examples: web apps, desktop apps, etc.) -etc.

Also Blender has coding guidelines that need to be followed in order for code to added to main repo, does Pharo has something similar ? If yes where is such a document ?

Not really (at least that I know). We should.

Also Blender mailing list is very active with major bug fixes and features enhancement , in Pharo it looks to me that a lot of this discussion is located to fogbug . That means however than unless you frequent there its very difficult to track changes that affect your workflow.

we still need to find the best workflow, yes. I’m not happy with fogbugz in general, not because of the tool, which is great (and I’m very grateful that we have it), but because it does not seems to adapt correctly to an open source project, or at least to our own project. Anyway, maybe if we continue the "moving to github” effort, probably we will prefer to use the github tracker, eventually (even if not as powerful as fogbugz).

Esteban

Not just Blender but many open source projects work similarly.

On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios@gmail.com>:

I can tell you why. Because its rarely is simple for people not familiar

...

with Pharo like me.

I once tried to help Damien with PharoLauncher. I added the progress bars you get when you download a new image it was simple as pie. Then Damien recommended for me to try to add support to PharoLauncher for CLI . I understand how Pharo does CLI stuff but was not able to understand anything about how PharoLauncher downloads and handles images. I literally spent hours trying to understand the internal architecture and gave up after 2 hours or so cause I had no clue how things worked.

Also finding a bug to fix in Pharo is time consuming, you have to go through one bug after another till you find that you can figure out whats wrong and how to fix. Its not easy and its very annoying at times.

Generally what kills me is lack of motivation, I don't like reading other's people code, I don't even like reading my code. I prefer documentation , If I am to fix a bug I want at least someone to show me how it works because figuring it by myself takes a lot of time and I am simply not willing to invest that time just because people find documentation something that should write one day when their software reaches version 1 meaning years later.

So you want to motivate people to contribute to bug fixes ? Do not allow any code to enter pharo main distribution without full class comments. I really mean "full class comment" not 2 , or 3 lines.

PBE has been left hanging years after the release of 1.4 , why ? you expect people to contribute to bug fixes even when the most basic of documentation is abandoned ?

Sorry if I sound harsh but you wanted a honest answer . For me undocumented code is far more annoying than a bug or a missing feature.

I find it a bit to harsh :) +1 for more source code documentation, but keep in mind that there are people that may not do proper documentation (even change code or fix bugs and don't document their code) but doing A LOT for pharo behind the scenes.

...

On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo@free.fr> wrote:

...

Hi guys

I'm sure that most of you did not realize it, but Pharo does not magically improve. It improves because some of us are looking at the tracker issues and looking at the code and improving it.

Since Pharo is yours I wonder why you do not take the time to improve. In fact, this is the key advantage of true open-source: being able to have an impact. An example, I was fed up to have a stupid widget to move method between protocol and classes between packages. I fixed it. It took my 20 min without knowing anything about Nautilus.

And it improved Pharo Right now, Right there. Of course if more people would be improving Pharo we could also focus on enabling technology and frameworks. But apparently we have to choose either we improve Pharo now or we invent cool stuff that takes time. I wonder why I do not go for the fame of writing a cool stuff instead of just improving systematically the system.

I wrote some roadmaps for people willing also to help.

https://github.com/pharo-project/pharo-workingRoadmaps

Stef

by the way here are the blender guidelines if someone wants to take a taste ---> http://wiki.blender.org/index.php/Dev:Doc/Code_Style <http://wiki.blender.org/index.php/Dev:Doc/Code_Style> On Tue, Aug 5, 2014 at 1:37 PM, kilon alios <kilon.alios@gmail.com> wrote:

Blender wiki is badly maintained because developers are only forced to document when they add a feature and not when they improve it etc So many of the pages are outdated , pictures are from version years ago and look very diffirent to modern versions of Blender. Its not a wiki problem its a maintance problem. But Blender has a huge community of video tutorials online. Even professional communities like Blendercookie and blenderguru. So it can afford to not care so much about keeping everything uptodate. Still people complain about the Blender wiki .

If Pharo accepts source code that at least has proper class comments then thats a big step forward. Even a hint of documentation is 1000 times better than no documentation at all. I think that this will definitely bring more people to contribute. I think I can also help there too. d

Blender also takes advantage of auto documentation, python offers doc strings, think of it as class comments and method comments with formatting. For example you can embed a unit test inside the class comment and the test will be runable by the user. The entire Blender API for python coders is auto documented this way. So I agree this a really good idea for documentation.

Also pharo people have done a great job with Pier and Pillar. Its definitely more powerful than a wiki and having a solution especially tailored for Pharo is a big plus. We dont need a wiki. As long as everything is linked back to the main website its fine. Pillar is much easier to learn than Latex and not very dissimilar to wiki syntax. I am very happy with pillar personally and Damien's conversion from Latex to Pillar works very well too.

Another good thing is that pharo documentation is really well written, there are things that are missing but most of it is a very good state. Its great not to have to rewrite documentation just because its not well understood. So its only a matter of keeping it updated.

On Tue, Aug 5, 2014 at 12:20 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 05 Aug 2014, at 11:05, kilon alios <kilon.alios@gmail.com> wrote:

I don't question people contribution to Pharo.

I do think however that we need to prioritize documentation. For example Blender development works in a way that a developers adding a feature to Blender main repo (not external code and external libraries) must add documentation to Blender wiki for the users.

+1 we do not like wikis (bah, I like them, but others don’t… and they have a point: a wiki must be maintained, otherwise is a waist of time and effort). but… since Pharo4 we started a practice which is: we do not integrate any new stuff that is not correctly commented (in classes), with tests and (if possible), examples.

in the long way this is the best because Pharo relies a lot in “autodocumentation”.

now, we can improve this: - even if new stuff has to come that way, most of the code inside image is poorly documented, tested and examples. We can improve that. We need to. I remember the comment per day Luc started a couple of years ago… is complicated to have them running in long way (until documentation is finished) because people get tired, but we could have a “two weeks comments” each three months or something like that. Not perfect, but better than what we have now. - I dream with PetitParser integrated into Pharo, and then a markdown/pillar parser into class comments, allowing us to have better formating and references, etc. to improve navigation.

and of course, more can be done: -tutorials for newbies (your work on the videos is great there, btw!) -example projects in different areas (I think the laser game is a good one, but we need more “professional” examples: web apps, desktop apps, etc.) -etc.

Also Blender has coding guidelines that need to be followed in order for code to added to main repo, does Pharo has something similar ? If yes where is such a document ?

Not really (at least that I know). We should.

Also Blender mailing list is very active with major bug fixes and features enhancement , in Pharo it looks to me that a lot of this discussion is located to fogbug . That means however than unless you frequent there its very difficult to track changes that affect your workflow.

we still need to find the best workflow, yes. I’m not happy with fogbugz in general, not because of the tool, which is great (and I’m very grateful that we have it), but because it does not seems to adapt correctly to an open source project, or at least to our own project. Anyway, maybe if we continue the "moving to github” effort, probably we will prefer to use the github tracker, eventually (even if not as powerful as fogbugz).

Esteban

Not just Blender but many open source projects work similarly.

On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios@gmail.com>:

I can tell you why. Because its rarely is simple for people not familiar

...

with Pharo like me.

I once tried to help Damien with PharoLauncher. I added the progress bars you get when you download a new image it was simple as pie. Then Damien recommended for me to try to add support to PharoLauncher for CLI . I understand how Pharo does CLI stuff but was not able to understand anything about how PharoLauncher downloads and handles images. I literally spent hours trying to understand the internal architecture and gave up after 2 hours or so cause I had no clue how things worked.

Also finding a bug to fix in Pharo is time consuming, you have to go through one bug after another till you find that you can figure out whats wrong and how to fix. Its not easy and its very annoying at times.

Generally what kills me is lack of motivation, I don't like reading other's people code, I don't even like reading my code. I prefer documentation , If I am to fix a bug I want at least someone to show me how it works because figuring it by myself takes a lot of time and I am simply not willing to invest that time just because people find documentation something that should write one day when their software reaches version 1 meaning years later.

So you want to motivate people to contribute to bug fixes ? Do not allow any code to enter pharo main distribution without full class comments. I really mean "full class comment" not 2 , or 3 lines.

PBE has been left hanging years after the release of 1.4 , why ? you expect people to contribute to bug fixes even when the most basic of documentation is abandoned ?

Sorry if I sound harsh but you wanted a honest answer . For me undocumented code is far more annoying than a bug or a missing feature.

I find it a bit to harsh :) +1 for more source code documentation, but keep in mind that there are people that may not do proper documentation (even change code or fix bugs and don't document their code) but doing A LOT for pharo behind the scenes.

...

On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo@free.fr> wrote:

...

Hi guys

I'm sure that most of you did not realize it, but Pharo does not magically improve. It improves because some of us are looking at the tracker issues and looking at the code and improving it.

Since Pharo is yours I wonder why you do not take the time to improve. In fact, this is the key advantage of true open-source: being able to have an impact. An example, I was fed up to have a stupid widget to move method between protocol and classes between packages. I fixed it. It took my 20 min without knowing anything about Nautilus.

And it improved Pharo Right now, Right there. Of course if more people would be improving Pharo we could also focus on enabling technology and frameworks. But apparently we have to choose either we improve Pharo now or we invent cool stuff that takes time. I wonder why I do not go for the fame of writing a cool stuff instead of just improving systematically the system.

I wrote some roadmaps for people willing also to help.

https://github.com/pharo-project/pharo-workingRoadmaps

Stef

Benjamin - I feel your pain. I went through the same thing - and I did try to help things by updating some of the information on the FogBugz wiki (which I think you found - at least the video). I know I hit a bunch of 404 errors too - which I corrected, but I can see that you hit a few more - so I've tried to fix them too. The Fogbugz wiki now points to the contributions wiki page (as that's easier to edit) - and then I've also pointed that page onto the pharo.org contributions page. I'm sure there are more corrections that can be made - if you ask Marcus, he can give you wiki edit priv's so you can correct things as well. However - there is a bigger question for the community, where should the main documentation be? We have some on the Fogbugz wiki and some on Pharo.org - and they conflict with each other? I would suggest that more generic/simple info should be on pharo.org (e.g. stuff that doesn't change too much, and that we can polish and make it look slick) - and then we link things back to Fogbugz where the details can be edited and updated by the wider community? (which is what I have tried to do having hit the same stumbling block as Benjamin). Tim -- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Okay, so that’s good, but you guys /really/ need to improve the documentation on the mechanical walkthrough of how to actually claim and submit a bug fix.

Today, I happened to have some spare time, so I figured, what the hell, why not see if I can’t fix some bugs blocking the Pharo 4 release. It’s a reach, granted, but I used to be good at Smalltalk, I’m still a good programmer, and I figure at least one of the blockers is in the really-annoying-but-technically-easy bucket that no one was willing to touch yet, so chances are good.

Armed with my old knowledge of how Squeak contrib used to work, I at least got as far as manually downloading a VM, manually downloading a .changes/.image, and manually downloading a .sources. Then I go to pharo.org <http://pharo.org> and…

Well, hmm. No instructions on the submission or development process? Well, no matter, I know you guys use FogBugz, so maybe on the FogBugz wiki? The landing page is unhelpful; clicking on the word “here” at “Reporting or Fixing a Bug?” takes me to http://pharo.org/get-involved which is a 404. Heading back, I try “Documentation”, which contains a lot of documentation, but none how to//submit fixes. You know the guy doing the video remove it because it was in rage against us. We were not aware that it was linked them.

Likewise, I can get great info on the workflow of a bug, but not on how to move code through that workflow.

At this point, by luck, I realize that there’s a link to “Contribute” in the TOC in FogBugz. Brilliant, exactly what I want! And it has a video walkthrough, no less, which takes me to http://vimeo.com/75183993 and…nope, that’s a 404 again. Thankfully, the link below it appears to let me download a nice MP4, which /does/ walk me through…submitting a slice. I actually have no idea if this is the right way to do things anymore, but given that you guys /seem/ to have a super-active GitHub repo, I kind of doubt it. And while there’s some documentation scattered around about how to use Git and Pharo, it’s not centralized or obvious.

It’s up to the community to be involved with the tools they love and to submit patches, and you’re totally right to remind everyone that it’s up to us to improve Pharo if we want to keep it alive, but it’s up to the core team to make sure that it’s easy for us to do so, and I think that Pharo’s not doing terribly well on that front right now.

We add a description on the old web site but he got lost. Now in a nutshell, to submit a fix - donwload latest image (there is a script on download) - do a fix for a giving bug - publish a slice press (+ slice) in MC, add the dirty packages - publish it in the inbox (click on inbox and press save) - take a fresh image. - reload it and check that it fixes the problem (open MC and click on inbox + open). Does it help? Was it so complex?

—Benjamin

Thats better - I think some overview text on the website and link to the wiki where more people can put finer details works very well. On the http://pharo.org/contribute-propose-fix page - perhaps we could do the same sort of thing too? I’m thinking maybe the following text might be better? (and we put the exact details of how to use Monticello and slices on the wiki) First check you meet the submission requirements and are familiar with the more detailed [contribution steps] (use link: https://pharo.fogbugz.com/default.asp?W68) In Summary you will do the following: Create or Verify there is an issue in the Fogbugz issue tracker (use link to https://pharo.fogbugz.com) Get the latest stable or development image, ideally using the latest virtual machine (check the download section). Create a code fix (ideally with a unit test exercising the working code) Create a Monticello slice (group of packages) using the MC browser, and add the dirty packages Publish the slice in the inbox Verify that your fix loads into a clean image Update the bug entry to mention that you have submitted a slice to the inbox On 7 Aug 2014, at 14:55, stepharo [via Smalltalk] <ml-node+s1294792n4772306h66@n4.nabble.com> wrote:

I added a description on the contribute page

http://pharo.org/contribute

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix): #How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need: - an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org) for the commit right). ##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox. You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement. <http://forum.world.st/file/n4772388/SliceMaker.png> -- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

in fact I just did a merge with the version of Tim and it is looking great. On 7/8/14 22:32, stepharo wrote:

Thanks martin I will have a look tomorrow.

Stef

On 7/8/14 22:11, MartinW wrote:

...

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix):

#How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need:

- an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)

for the commit right).

##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox.

You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement.

<http://forum.world.st/file/n4772388/SliceMaker.png>

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Ok - I’ve fixed my faux-pas and propose the following text (a slight rework of what is published now). Taking a hint from Martin there is a notehub link here (http://notehub.org/2014/8/8/how-to-propose-a-bug-fix-or-enhancement) - although I’ve noticed notehub handles sub-bullets a bit strangely. We might also want to do another slight change if we agree that Fogbugz should be secondary content (if so - adjust the first paragraph to something like: Check if your change has already been entered into Fogbugz, and consider watching the overview video of the steps documented below.) #How to propose a bug fix or enhancement First check you meet the submission requirements and are familiar with the more detailed [contribution steps](https://pharo.fogbugz.com/default.asp?W68) (watch the [tutorial video](https://pharo.fogbugz.com/default.asp?pg=pgDownload&pgType=pgWikiAttachment&...), it's great!) ##Prerequisites In order to propose a bug fix or enhancement for Pharo you need: - An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com), - An account on [SmalltalkHub](http://smalltalkhub.com) with rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox). _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)._ ##Procedure To commit a change, you will follow these steps: - Take the latest [stable or development system](http://pharo.org/download), ideally using the latest virtual machine for your OS - Ensure you have created [details of the issue in the Fogbugz issue tracker] (https://pharo.fogbugz.com) - Create a code fix (ideally with a [unit test](http://pharo.gforge.inria.fr/PBE1/PBE1ch8.html) exercising the working code) - Create a Monticello Slice (group of packages) for your changes: - Open the Monticello Browser - Open the Slice Maker by clicking the "Slice" button - In Slice Maker enter the Fogbugz issue number and "grab" the issue summary - Select all dirty packages affected by your fix - Verify your changes (click the Changes button) - Select the Pharo40 repository - Select your Slice - Press changes in the Monticello Browser and verify that your changes are correct - Publish the Slice to the inbox: - Select the whole Slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit the Slice. - Verify that your fix loads: - Take a fresh image and load the Slice you just published - Update the bug entry to mention that you submitted a Slice in the inbox - Now sit back and feel good! You've helped influence a brighter future... You can also contribute to Pharo by proposing enhancements on the mailing list and/or by submitting a Fogbugz issue. Note that all code submitted to the [Pharo repositories](http://smalltalkhub.com/#!/~Pharo) is licensed under the [MIT license]http://opensource.org/licenses/MIT). Do not forget to sign the [license agreement](http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf). On 8 Aug 2014, at 07:16, Tim Mackinnon <tim@testit.works> wrote:

Stef - I've confused you with my suggestion. Where I wrote "use link" after the text in [] - I meant put that hyperlink for the [text].

Sorry, I was writing my reply in a text editor and was doing a sort of pseudo markdown syntax.

Looking at where this is going - maybe we should instead make the Pharo.org site the main source of info and not Fogbugz? We have a duplication problem - and when things change we end up with conflicting instructions as we forget to update the other copies. Essentially we need to refactor the docs.

Is Pharo.org easily editable by others (is this the Pillar bit?). If it was then I would say let's edit the Fogbugz pages - simplify them and point them back to the more detailed Pharo.org pages.

For now, I will find a laptop and send some cleaned up text.

Tim

Sent from my iPhone

On 7 Aug 2014, at 10:45 pm, "stepharo [via Smalltalk]" <[hidden email]> wrote:

...

in fact I just did a merge with the version of Tim and it is looking great. On 7/8/14 22:32, stepharo wrote:

...

Thanks martin I will have a look tomorrow.

Stef

On 7/8/14 22:11, MartinW wrote:

...

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix):

#How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need:

- an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)

for the commit right).

##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox.

You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement.

<http://forum.world.st/file/n4772388/SliceMaker.png>

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

View this message in context: Re: About your contributions: Improve Pharo right now, right there. Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Yes - it would be better to link to the YouTube version in the text. So how is the Pharo.org site generated? Is this what Pillar is? (Is it a pier wiki?) and could we easily help with editing a subsection of it to help out? Tim Sent from my iPhone

On 8 Aug 2014, at 10:52 am, "phil@highoctane.be" <phil@highoctane.be> wrote:

I've uploaded the video on my channel as well.

https://www.youtube.com/watch?v=iFomI-7h4qQ ​ Phil

Hi, We love to have contributions, but for the moment being (to try to keep the design, etc. and prevent too much disorder… which was a problem in the previous site). I would prefer you to send me your contributions (or post it here), and I will upload them to the site. cheers, Esteban On 08 Aug 2014, at 12:11, Tim Mackinnon <tim@testit.works> wrote:

Yes - it would be better to link to the YouTube version in the text.

So how is the Pharo.org site generated? Is this what Pillar is? (Is it a pier wiki?) and could we easily help with editing a subsection of it to help out?

Tim

Sent from my iPhone

On 8 Aug 2014, at 10:52 am, "phil@highoctane.be" <phil@highoctane.be> wrote:

...

I've uploaded the video on my channel as well.

https://www.youtube.com/watch?v=iFomI-7h4qQ ​ Phil

Bump? The text on http://pharo.org/contribute-propose-fix is still wrong - can someone include the text I fixed up below? Also - do we want to make pharo.org the primary place for docs (and hence change the first paragraph to: #How to propose a bug fix or enhancement First check if your change has already been entered into Fogbugz, and consider watching the [overview video](https://www.youtube.com/watch?v=iFomI-7h4qQ) of the steps documented below. If we want to move away from the Fogbugz wiki, I will also simplify some of the text and point it back to pharo.org. Tim On 8 Aug 2014, at 08:40, Tim Mackinnon <tim@testit.works> wrote:

Ok - I’ve fixed my faux-pas and propose the following text (a slight rework of what is published now). Taking a hint from Martin there is a notehub link here (http://notehub.org/2014/8/8/how-to-propose-a-bug-fix-or-enhancement) - although I’ve noticed notehub handles sub-bullets a bit strangely. We might also want to do another slight change if we agree that Fogbugz should be secondary content (if so - adjust the first paragraph to something like: Check if your change has already been entered into Fogbugz, and consider watching the overview video of the steps documented below.)

——

#How to propose a bug fix or enhancement First check you meet the submission requirements and are familiar with the more detailed [contribution steps](https://pharo.fogbugz.com/default.asp?W68) (watch the [tutorial video](https://pharo.fogbugz.com/default.asp?pg=pgDownload&pgType=pgWikiAttachment&...), it's great!)

##Prerequisites In order to propose a bug fix or enhancement for Pharo you need:

- An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com), - An account on [SmalltalkHub](http://smalltalkhub.com) with rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox). _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)._

##Procedure To commit a change, you will follow these steps:

- Take the latest [stable or development system](http://pharo.org/download), ideally using the latest virtual machine for your OS - Ensure you have created [details of the issue in the Fogbugz issue tracker] (https://pharo.fogbugz.com) - Create a code fix (ideally with a [unit test](http://pharo.gforge.inria.fr/PBE1/PBE1ch8.html) exercising the working code) - Create a Monticello Slice (group of packages) for your changes: - Open the Monticello Browser - Open the Slice Maker by clicking the "Slice" button - In Slice Maker enter the Fogbugz issue number and "grab" the issue summary - Select all dirty packages affected by your fix - Verify your changes (click the Changes button) - Select the Pharo40 repository - Select your Slice - Press changes in the Monticello Browser and verify that your changes are correct - Publish the Slice to the inbox: - Select the whole Slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit the Slice. - Verify that your fix loads: - Take a fresh image and load the Slice you just published - Update the bug entry to mention that you submitted a Slice in the inbox - Now sit back and feel good! You've helped influence a brighter future...

You can also contribute to Pharo by proposing enhancements on the mailing list and/or by submitting a Fogbugz issue. Note that all code submitted to the [Pharo repositories](http://smalltalkhub.com/#!/~Pharo) is licensed under the [MIT license]http://opensource.org/licenses/MIT). Do not forget to sign the [license agreement](http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf).

On 8 Aug 2014, at 07:16, Tim Mackinnon <tim@testit.works> wrote:

...

Stef - I've confused you with my suggestion. Where I wrote "use link" after the text in [] - I meant put that hyperlink for the [text].

Sorry, I was writing my reply in a text editor and was doing a sort of pseudo markdown syntax.

Looking at where this is going - maybe we should instead make the Pharo.org site the main source of info and not Fogbugz? We have a duplication problem - and when things change we end up with conflicting instructions as we forget to update the other copies. Essentially we need to refactor the docs.

Is Pharo.org easily editable by others (is this the Pillar bit?). If it was then I would say let's edit the Fogbugz pages - simplify them and point them back to the more detailed Pharo.org pages.

For now, I will find a laptop and send some cleaned up text.

Tim

Sent from my iPhone

On 7 Aug 2014, at 10:45 pm, "stepharo [via Smalltalk]" <[hidden email]> wrote:

...

in fact I just did a merge with the version of Tim and it is looking great. On 7/8/14 22:32, stepharo wrote:

...

Thanks martin I will have a look tomorrow.

Stef

On 7/8/14 22:11, MartinW wrote:

...

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix):

#How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need:

- an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)

for the commit right).

##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox.

You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement.

<http://forum.world.st/file/n4772388/SliceMaker.png>

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

View this message in context: Re: About your contributions: Improve Pharo right now, right there. Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Thanks Esteban, that’s definitely (minor point: you didn’t use the same text I gave you below, so there are some grammatical errors on the site). If you want to keep control of how things are published - maybe it makes sense, and is much easier to set the rule: “Give me a complete page with changes in XXXX format” (you tell me what XXX is - markdown?). And then we can send you full pages you can paste in (and diff?) For now - can you also change the first paragraph, I think it makes more sense to say that Pharo.org is the main place for information, and so its much better to write: #How to propose a bug fix or enhancement First check if your change has already been entered into [Fogbugz](https://pharo.fogbugz.com/), and consider watching the [overview video](https://www.youtube.com/watch?v=iFomI-7h4qQ) of the steps documented below. Can you also change the Pre-reqs section to fix some minor typos (and match the formatting of the text further down) ##Prerequisites In order to propose a bug fix or enhancement for Pharo you need: - An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com), - An account on [SmalltalkHub](http://smalltalkhub.com) with commit rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox). _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)._

Tim On 12 Aug 2014, at 12:30, EstebanLM [via Smalltalk] <ml-node+s1294792n4772981h91@n4.nabble.com> wrote:

On 11 Aug 2014, at 18:28, Tim Mackinnon <[hidden email]> wrote:

...

Bump? The text on http://pharo.org/contribute-propose-fix is still wrong - can someone include the text I fixed up below?

fixed

Esteban

...

Also - do we want to make pharo.org the primary place for docs (and hence change the first paragraph to:

#How to propose a bug fix or enhancement First check if your change has already been entered into Fogbugz, and consider watching the [overview video](https://www.youtube.com/watch?v=iFomI-7h4qQ) of the steps documented below.

If we want to move away from the Fogbugz wiki, I will also simplify some of the text and point it back to pharo.org.

Tim

On 8 Aug 2014, at 08:40, Tim Mackinnon <[hidden email]> wrote:

...

Ok - I’ve fixed my faux-pas and propose the following text (a slight rework of what is published now). Taking a hint from Martin there is a notehub link here (http://notehub.org/2014/8/8/how-to-propose-a-bug-fix-or-enhancement) - although I’ve noticed notehub handles sub-bullets a bit strangely. We might also want to do another slight change if we agree that Fogbugz should be secondary content (if so - adjust the first paragraph to something like: Check if your change has already been entered into Fogbugz, and consider watching the overview video of the steps documented below.)

——

...

#How to propose a bug fix or enhancement First check you meet the submission requirements and are familiar with the more detailed [contribution steps](https://pharo.fogbugz.com/default.asp?W68) (watch the [tutorial video](https://pharo.fogbugz.com/default.asp?pg=pgDownload&pgType=pgWikiAttachment&...), it's great!)

##Prerequisites In order to propose a bug fix or enhancement for Pharo you need:

- An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com), - An account on [SmalltalkHub](http://smalltalkhub.com) with rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox). _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)._

##Procedure To commit a change, you will follow these steps:

- Take the latest [stable or development system](http://pharo.org/download), ideally using the latest virtual machine for your OS - Ensure you have created [details of the issue in the Fogbugz issue tracker] (https://pharo.fogbugz.com) - Create a code fix (ideally with a [unit test](http://pharo.gforge.inria.fr/PBE1/PBE1ch8.html) exercising the working code) - Create a Monticello Slice (group of packages) for your changes: - Open the Monticello Browser - Open the Slice Maker by clicking the "Slice" button - In Slice Maker enter the Fogbugz issue number and "grab" the issue summary - Select all dirty packages affected by your fix - Verify your changes (click the Changes button) - Select the Pharo40 repository - Select your Slice - Press changes in the Monticello Browser and verify that your changes are correct - Publish the Slice to the inbox: - Select the whole Slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit the Slice. - Verify that your fix loads: - Take a fresh image and load the Slice you just published - Update the bug entry to mention that you submitted a Slice in the inbox - Now sit back and feel good! You've helped influence a brighter future...

You can also contribute to Pharo by proposing enhancements on the mailing list and/or by submitting a Fogbugz issue. Note that all code submitted to the [Pharo repositories](http://smalltalkhub.com/#!/~Pharo) is licensed under the [MIT license]http://opensource.org/licenses/MIT). Do not forget to sign the [license agreement](http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf).

On 8 Aug 2014, at 07:16, Tim Mackinnon <[hidden email]> wrote:

...

Stef - I've confused you with my suggestion. Where I wrote "use link" after the text in [] - I meant put that hyperlink for the [text].

Sorry, I was writing my reply in a text editor and was doing a sort of pseudo markdown syntax.

Looking at where this is going - maybe we should instead make the Pharo.org site the main source of info and not Fogbugz? We have a duplication problem - and when things change we end up with conflicting instructions as we forget to update the other copies. Essentially we need to refactor the docs.

Is Pharo.org easily editable by others (is this the Pillar bit?). If it was then I would say let's edit the Fogbugz pages - simplify them and point them back to the more detailed Pharo.org pages.

For now, I will find a laptop and send some cleaned up text.

Tim

Sent from my iPhone

On 7 Aug 2014, at 10:45 pm, "stepharo [via Smalltalk]" <<a href="x-msg://28/user/SendEmail.jtp?type=node&node=4772414&i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote:

...

in fact I just did a merge with the version of Tim and it is looking great. On 7/8/14 22:32, stepharo wrote:

...

Thanks martin I will have a look tomorrow.

Stef

On 7/8/14 22:11, MartinW wrote:

...

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix):

#How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need:

- an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org)

for the commit right).

##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox.

You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement.

<http://forum.world.st/file/n4772388/SliceMaker.png>

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

View this message in context: Re: About your contributions: Improve Pharo right now, right there. Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

I’d never heard of notehub before - looks handy. I was initially worried we had yet another copy of documentation to worry about, but I think I’ve understood your intent was to make it easier for Stef to nab your changes. I’ll make a mental note to try it to. Tim On 7 Aug 2014, at 21:11, MartinW [via Smalltalk] <ml-node+s1294792n4772388h8@n4.nabble.com> wrote:

Could you extend http://pharo.org/contribute-propose-fix a bit? And add a screenshot of Slice Maker (I attach one). The following text would have helped me (I paste the markdown. I also posted it on NoteHub for a better reading experience http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix):

#How to propose a bug fix: ##Prerequesites: In order to propose a bug fix or enhancement for Pharo you need:

- an account at the [Pharo Issue Tracker on Fogbugz](https://pharo.fogbugz.com), - a [SmalltalkHub](http://smalltalkhub.com) account and - the commit right for the [Pharo Inbox on SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on the [Pharo Developers mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org) for the commit right).

##Procedure: - Take the latest stable or latest development system, ideally using the latest virtual machine. - Do a fix for a given bug, or a new bug you entered to the issue tracker. - Create a slice (group of packages): - Open the Monticello Browser. - Open the Slice Maker by clicking the **+Slice** button. - In Slice Maker enter the Fogbugz issue number and **grab** the issue summary. - Select all dirty packages affected by your bug fix. - Publish the slice to the inbox: - Select the whole slice (not it's individual packages). - Select the SmalltalkHub Pharo Inbox repository. - Commit your slice. - Verify that your fix loads: take a fresh image and load the slice you published. - Update the bug entry to mention that you submitted a slice in the inbox.

You can also contribute to Pharo by proposing enhancements following the same process. Note that all code submitted to the Pharo repositories is licensed under the MIT license. Do not forget to sign the license agreement.

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On Aug 7, 2014, at 9:47 AM, stepharo <stepharo@free.fr> wrote:

...

It’s up to the community to be involved with the tools they love and to submit patches, and you’re totally right to remind everyone that it’s up to us to improve Pharo if we want to keep it alive, but it’s up to the core team to make sure that it’s easy for us to do so, and I think that Pharo’s not doing terribly well on that front right now.

We add a description on the old web site but he got lost. Now in a nutshell, to submit a fix

- donwload latest image (there is a script on download) - do a fix for a giving bug - publish a slice press (+ slice) in MC, add the dirty packages - publish it in the inbox (click on inbox and press save) - take a fresh image. - reload it and check that it fixes the problem (open MC and click on inbox + open).

Does it help? Was it so complex?

Yep, it helps. The issue isn’t that it was complex; it’s that it was undocumented. The new links are helpful.

Yes it's a good video - it helped me a lot. There is one small correction I've meant to add below it - the step for getting write access to the inbox isn't currently needed (but I guess closer to a release that might change). Tim Sent from my iPhone

On 7 Aug 2014, at 10:13 pm, "stepharo [via Smalltalk]" <ml-node+s1294792n4772389h39@n4.nabble.com> wrote:

I'm happy that the video made by camillo is still served by the fogbugs web site because it explains really well the process.

Stef

On 7/8/14 21:48, Benjamin Pollack wrote:

...

On Aug 7, 2014, at 9:47 AM, stepharo <[hidden email]> wrote:

...

...

It’s up to the community to be involved with the tools they love and to submit patches, and you’re totally right to remind everyone that it’s up to us to improve Pharo if we want to keep it alive, but it’s up to the core team to make sure that it’s easy for us to do so, and I think that Pharo’s not doing terribly well on that front right now.

We add a description on the old web site but he got lost. Now in a nutshell, to submit a fix

- donwload latest image (there is a script on download) - do a fix for a giving bug - publish a slice press (+ slice) in MC, add the dirty packages - publish it in the inbox (click on inbox and press save) - take a fresh image. - reload it and check that it fixes the problem (open MC and click on inbox + open).

Does it help? Was it so complex? Yep, it helps. The issue isn’t that it was complex; it’s that it was undocumented. The new links are helpful.

Excellent! You will that getting your first fixes in the system is a great and cool feeling.

...

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. NAML

-- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-right... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.