Re: [Sugar-devel] first-time only issues
I meant these trivial tasks should just be for providing confidence to the newcomers so that they can at least get started. It may be less productive but will help them keep going. We can also have a *Suggestions *section on the readme of every repo. I just thought about this. And there can be a new set of issues on every repo to come up with 2 specific suggestions, say - Come up with an updated look of specific section of an activity/website - Come up with a latest idea of some specific functionality - Come up with two new feature suggestions for xyz activity/website - Find redundant codes etc. I strongly feel some of the suggestions could be worth having and may be such that we have not thought about it so far. But overall these will be a basic reason for the newcomers to go through the code base and start helping. After having an understanding of the code base, our mission, and our community, it may be onto them how longer they want to be a part of us. All in all, there has to be a *Why? *for every question, then only we could maximize our potential. For instance, if the following Why?'s could be answered properly, it will mean we are going in right direction otherwise we need to find the answer to these Why?'s. Some of them are - Why should a newcomer contribute? - Why should past contributor keep contributing? - Why should I learn something new for SugarLabs? *If none sounds good, I have another idea!* Can we have a seasonal/monthly/quarterly competition for the newcomers? We may have SugarLabs T-shirt or some other award for the top 3-5 contributors. Here newcomers may be defined as anyone with less than 50 commits or so. Also, SugarLabs T-Shirt will be another reason for Offline Publicity and hence will encourage the friends of the winners to compete next time. I find it much more interesting to be honest. What do you think? (Any newcomer to sugar-devel, please feel free to share what do you think about this) Thanks, Amaan On May 3, 2019 11:32 AM, "James Cameron" wrote: > Thanks. Yes, it makes sense. > > But it is like directing an investigation. A true and well-done > investigation is one where the investigator is independent of bias. > > When we bias the newcomers toward certain tasks, we tend only to get > those tasks done. An example is how we've had many activities ported > to GTK 3 and still not yet released. > > I've got "Maintain an activity" on my "How to get started as a Sugar > Labs developer"; > > http://lists.sugarlabs.org/archive/sugar-devel/2019-April/056615.html > > And also on our "Contribute code" > > > https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#modifying-activities > > There seems to be a hope that the reason why we don't have newcomers > doing this is because they find it too hard, and they want something > easier, like changing colours. > > I'm not sure that this is true. I think the reasons why we don't have > newcomers doing anything this are far more profound; > > 1. very few other people are doing anything; development has slowed, > > 2. work done by others earlier has not been merged, or not released, > > 3. there are more interesting things to do, > > A way to be sure is to ask our newcomers why they chose not to do > anything. Or why a newcomer made a few patches and did not help to > get an activity released. We might also ask the oldtimers why they > have chosen not to help, or not to learn new skills. > > On Fri, May 03, 2019 at 11:08:44AM +0530, Amaan Iqbal wrote: > > I meant if the color palette update(actual update in the code), > Improvised look > > (in the code), suggestion etc is of some value, then their PR can > directly be > > merged. > > > > Also we can have a section in each repo Readme for some 'expected > > functionalities' to have, which the newcomers can directly update. So > that they > > can get the feel of getting the PR merged. > > > > For redundant codes, the newcomers may find 2 places where similar code > is > > appearing and remove either of them and send corresponding PR. > > > > Regarding console errors, we may have basic issues, specific to each > error say > > of datatype mismatch etc which doesn't block the expected behavior but > better > > to fix them. These issues can be worked upon by the newcomers and will > require > > finding out which module is located where. This will help them dig > deeper into > > the code base and contribute further. > > > > I hope it makes sense. > > > > Thanks, > > Amaan > > > > On May 3, 2019 9:37 AM, "James Cameron" <[1]qu...@laptop.org> wrote: > > > > Interesting idea. But I've an ethical problem with creating issues > > that don't need to be fixed, and will never merge. It seems > arbitrary > > and unfair to a new contributor. > > > > On the other hand, some of the issues you listed have general value; > > such as minimising console output. > > > > On Fri, May 03, 2019 at 09:05:07AM +0530, Amaan Iqbal wrote: >
Re: [Sugar-devel] first-time only issues
Incredible! We are having trouble identifying tasks that need doing. Try: Over 100 Sugar Activities in ASLO which fail to start. Many activities which do not have a repository in github.com/sugarlabs Many activities still dependent on gtk3 and other deprecated moduless Tony On 5/3/19 2:02 PM, James Cameron wrote: Thanks. Yes, it makes sense. But it is like directing an investigation. A true and well-done investigation is one where the investigator is independent of bias. When we bias the newcomers toward certain tasks, we tend only to get those tasks done. An example is how we've had many activities ported to GTK 3 and still not yet released. I've got "Maintain an activity" on my "How to get started as a Sugar Labs developer"; http://lists.sugarlabs.org/archive/sugar-devel/2019-April/056615.html And also on our "Contribute code" https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#modifying-activities There seems to be a hope that the reason why we don't have newcomers doing this is because they find it too hard, and they want something easier, like changing colours. I'm not sure that this is true. I think the reasons why we don't have newcomers doing anything this are far more profound; 1. very few other people are doing anything; development has slowed, 2. work done by others earlier has not been merged, or not released, 3. there are more interesting things to do, A way to be sure is to ask our newcomers why they chose not to do anything. Or why a newcomer made a few patches and did not help to get an activity released. We might also ask the oldtimers why they have chosen not to help, or not to learn new skills. On Fri, May 03, 2019 at 11:08:44AM +0530, Amaan Iqbal wrote: I meant if the color palette update(actual update in the code), Improvised look (in the code), suggestion etc is of some value, then their PR can directly be merged. Also we can have a section in each repo Readme for some 'expected functionalities' to have, which the newcomers can directly update. So that they can get the feel of getting the PR merged. For redundant codes, the newcomers may find 2 places where similar code is appearing and remove either of them and send corresponding PR. Regarding console errors, we may have basic issues, specific to each error say of datatype mismatch etc which doesn't block the expected behavior but better to fix them. These issues can be worked upon by the newcomers and will require finding out which module is located where. This will help them dig deeper into the code base and contribute further. I hope it makes sense. Thanks, Amaan On May 3, 2019 9:37 AM, "James Cameron" <[1]qu...@laptop.org> wrote: Interesting idea. But I've an ethical problem with creating issues that don't need to be fixed, and will never merge. It seems arbitrary and unfair to a new contributor. On the other hand, some of the issues you listed have general value; such as minimising console output. On Fri, May 03, 2019 at 09:05:07AM +0530, Amaan Iqbal wrote: > I have a suggestion here. We may create some issues with beginner labels, such > that solving it may not be really helpful to us at first, but it can give > insights of the code base to the new contributors. > > For instance, an issue for trying new color palette for our SugarLabs website. > Or an issue for trying different border radius, color to a section of any > activity etc. > > These may be useful in the long run especially if a new contributor can come up > with something out of the box. Or atleast it will help them get familiar to our > code base. > > These can be marked as 'reserved for beginners'. Some examples of these issue > can be > * Try color palette ABC to our website > * Try color palette EFG to our website > * Change the border radius of xyz element to make it look better > * Update padding/look of xyz section of abc activity > * Come up with 2 instances of redundant codes in xyz repo of SugarLabs > * Come up with the idea of 2 features improvement for xyz repo > * Come up with an idea to implement xyz functionality > * Minimize console errors of abc activity > > I guess some of these would be interesting to the user even if they don't know > how to code. It will definitely help in attracting a good number of new > contributors. > > Also, it would not affect the development time of the experienced contributors > since these issues would not require deep understanding of the code base or any > skill. > > Thanks, > Amaan > > > On May 3, 2019 4:07 AM, "James Cameron" <[1][2]qu...@laptop.org> wrote: > > You're saying leave some flaws rather than fix them. > > In general that's a good idea for attracting new
Re: [Sugar-devel] first-time only issues
On Fri, May 03, 2019 at 04:02:03PM +1000, James Cameron wrote: > I'm not sure that this is true. I think the reasons why we don't have > newcomers doing anything this are far more profound; > > 1. very few other people are doing anything; development has slowed, > > 2. work done by others earlier has not been merged, or not released, > > 3. there are more interesting things to do, ... and they are not paying attention to the fundamental problems we have. -- James Cameron http://quozl.netrek.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] first-time only issues
Thanks. Yes, it makes sense. But it is like directing an investigation. A true and well-done investigation is one where the investigator is independent of bias. When we bias the newcomers toward certain tasks, we tend only to get those tasks done. An example is how we've had many activities ported to GTK 3 and still not yet released. I've got "Maintain an activity" on my "How to get started as a Sugar Labs developer"; http://lists.sugarlabs.org/archive/sugar-devel/2019-April/056615.html And also on our "Contribute code" https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#modifying-activities There seems to be a hope that the reason why we don't have newcomers doing this is because they find it too hard, and they want something easier, like changing colours. I'm not sure that this is true. I think the reasons why we don't have newcomers doing anything this are far more profound; 1. very few other people are doing anything; development has slowed, 2. work done by others earlier has not been merged, or not released, 3. there are more interesting things to do, A way to be sure is to ask our newcomers why they chose not to do anything. Or why a newcomer made a few patches and did not help to get an activity released. We might also ask the oldtimers why they have chosen not to help, or not to learn new skills. On Fri, May 03, 2019 at 11:08:44AM +0530, Amaan Iqbal wrote: > I meant if the color palette update(actual update in the code), Improvised > look > (in the code), suggestion etc is of some value, then their PR can directly be > merged. > > Also we can have a section in each repo Readme for some 'expected > functionalities' to have, which the newcomers can directly update. So that > they > can get the feel of getting the PR merged. > > For redundant codes, the newcomers may find 2 places where similar code is > appearing and remove either of them and send corresponding PR. > > Regarding console errors, we may have basic issues, specific to each error say > of datatype mismatch etc which doesn't block the expected behavior but better > to fix them. These issues can be worked upon by the newcomers and will require > finding out which module is located where. This will help them dig deeper into > the code base and contribute further. > > I hope it makes sense. > > Thanks, > Amaan > > On May 3, 2019 9:37 AM, "James Cameron" <[1]qu...@laptop.org> wrote: > > Interesting idea. But I've an ethical problem with creating issues > that don't need to be fixed, and will never merge. It seems arbitrary > and unfair to a new contributor. > > On the other hand, some of the issues you listed have general value; > such as minimising console output. > > On Fri, May 03, 2019 at 09:05:07AM +0530, Amaan Iqbal wrote: > > I have a suggestion here. We may create some issues with beginner > labels, > such > > that solving it may not be really helpful to us at first, but it can > give > > insights of the code base to the new contributors. > > > > For instance, an issue for trying new color palette for our SugarLabs > website. > > Or an issue for trying different border radius, color to a section of > any > > activity etc. > > > > These may be useful in the long run especially if a new contributor can > come up > > with something out of the box. Or atleast it will help them get familiar > to our > > code base. > > > > These can be marked as 'reserved for beginners'. Some examples of these > issue > > can be > > * Try color palette ABC to our website > > * Try color palette EFG to our website > > * Change the border radius of xyz element to make it look better > > * Update padding/look of xyz section of abc activity > > * Come up with 2 instances of redundant codes in xyz repo of SugarLabs > > * Come up with the idea of 2 features improvement for xyz repo > > * Come up with an idea to implement xyz functionality > > * Minimize console errors of abc activity > > > > I guess some of these would be interesting to the user even if they > don't > know > > how to code. It will definitely help in attracting a good number of new > > contributors. > > > > Also, it would not affect the development time of the experienced > contributors > > since these issues would not require deep understanding of the code base > or any > > skill. > > > > Thanks, > > Amaan > > > > > > On May 3, 2019 4:07 AM, "James Cameron" <[1][2]qu...@laptop.org> wrote: > > > > You're saying leave some flaws rather than fix them. > > > > In general that's a good idea for attracting new members to a > > community, but it takes investment in preparing the issue, and if > that > > investment is greater than fixing the flaw there's not much benefit. > > >
