[yast-devel] Topic days for the Yast team?
Hi all, I have an interesting idea for the Yast team. What about starting "topic days" events regularly? Some upstream projects do for example "bug squashing days", we could do something similar. Pros: + whole team is focused on one topic, we could get more ideas, opinions, better find a solution which works for more yast modules... + doing the same in all modules at once means we use the same (or similar) solution in all Yast modules, we can easily unify the solution + doing the work in parallel for many developers mean it will be done fast (or finished in the end, sometimes I fix/improve something in one module but do not have enough time to do it in all other Yast repos...) + improves team spirit and team cooperation + the team as whole learns something new Cons: - the date and the topic needs to be set in advance - needs some preparation in advance, someone has to lead the project - does not work for all projects, the project needs to scale easily (i.e. it does not need any deep knowledge about the module, the task needs to be generic enough for all developers) The project should take max. few hours for each developer, the real power is in the massive[1] parallel work. I have some example topics/projects which we could try: - Improve Yast README files (as discussed in a separate thread) - Fix yardoc documentation comments. Many Yast modules print warnings when building the docs, usually there are typos (@return vs. @returns), obsoleted/missing parameters, typos in type names... which can be easily fixed without any knowledge of the module. - Convert old tests to RSpec - Use coveralls for code coverage status - Use rubocop for checking the code For tracking the status we could use a google docs spreadsheet, it worked well for us in the YCP killer project. We knew the overall progress, who was working on what (no conflicts)... Of course, your participation would not be mandatory, if you would not like a specific project or you would have something more important to do (L3s...) then you would not have to join. What do you think about it? Would you participate in such event? Do you have more ideas what projects we could do? Thanks for your response! [1] Well, with the rather small team we have it cannot be that "massive", but anyway... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 02 Mar 2015 18:38:46 +0100
Ladislav Slezak
Hi all,
I have an interesting idea for the Yast team. What about starting "topic days" events regularly? Some upstream projects do for example "bug squashing days", we could do something similar.
Pros:
+ whole team is focused on one topic, we could get more ideas, opinions, better find a solution which works for more yast modules... + doing the same in all modules at once means we use the same (or similar) solution in all Yast modules, we can easily unify the solution + doing the work in parallel for many developers mean it will be done fast (or finished in the end, sometimes I fix/improve something in one module but do not have enough time to do it in all other Yast repos...) + improves team spirit and team cooperation + the team as whole learns something new
Cons:
- the date and the topic needs to be set in advance - needs some preparation in advance, someone has to lead the project - does not work for all projects, the project needs to scale easily (i.e. it does not need any deep knowledge about the module, the task needs to be generic enough for all developers)
The project should take max. few hours for each developer, the real power is in the massive[1] parallel work.
I have some example topics/projects which we could try:
- Improve Yast README files (as discussed in a separate thread)
- Fix yardoc documentation comments. Many Yast modules print warnings when building the docs, usually there are typos (@return vs. @returns), obsoleted/missing parameters, typos in type names... which can be easily fixed without any knowledge of the module.
- Convert old tests to RSpec
- Use coveralls for code coverage status
- Use rubocop for checking the code
For tracking the status we could use a google docs spreadsheet, it worked well for us in the YCP killer project. We knew the overall progress, who was working on what (no conflicts)...
Of course, your participation would not be mandatory, if you would not like a specific project or you would have something more important to do (L3s...) then you would not have to join.
What do you think about it? Would you participate in such event? Do you have more ideas what projects we could do?
Thanks for your response!
[1] Well, with the rather small team we have it cannot be that "massive", but anyway...
Hi, I think it is great idea. Also some bug squashing would be nice to organize for modules with huge bugzilla queue. ( bug squashing does not mean fixing bug, just try to reproduce it on the latest distro and if so, then try to fix it or provide your test env for developer of module ). Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 02 Mar 2015 18:38:46 +0100 Ladislav Slezak
wrote: [...] I have some example topics/projects which we could try:
- Improve Yast README files (as discussed in a separate thread)
- Fix yardoc documentation comments. Many Yast modules print warnings when building the docs, usually there are typos (@return vs. @returns), obsoleted/missing parameters, typos in type names... which can be easily fixed without any knowledge of the module.
- Convert old tests to RSpec
- Use coveralls for code coverage status
- Use rubocop for checking the code
On Mon, Mar 02, 2015 at 06:46:43PM +0100, Josef Reidinger wrote:
I think it is great idea. Also some bug squashing would be nice to organize for modules with huge bugzilla queue. ( bug squashing does not mean fixing bug, just try to reproduce it on the latest distro and if so, then try to fix it or provide your test env for developer of module
Yes, all good ideas. Let's start with the readmes. -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On 3.3.2015 15:09, Martin Vidner wrote:
On Mon, Mar 02, 2015 at 06:46:43PM +0100, Josef Reidinger wrote:
I think it is great idea. Also some bug squashing would be nice to organize for modules with huge bugzilla queue. ( bug squashing does not mean fixing bug, just try to reproduce it on the latest distro and if so, then try to fix it or provide your test env for developer of module
Yes, all good ideas. Let's start with the readmes.
Thanks, all this is a very good idea, including starting with READMEs. Additionally, I think that there should be a short brainstorming prior to a particular "topic day" where we would briefly discuss what we want to achieve and how. The output from the brainstorming should be some kind of meeting minutes describing the subject, goals, and the way to get there, so everyone would be at the same page ~ e.g., Etherpad page :) Then we could start hacking the very next day. For finding the best date for a "Topic Day", I recommend using Doodle, the same for the brainstorming. BTW, everyone, including community should be free to join. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Josef Reidinger
-
Ladislav Slezak
-
Lukas Ocilka
-
Martin Vidner