torios team mailing list archive
Mailing list archive
Re: attracting volunteers (was Re: Manual Update 3/4/2019)
Momozor <skelic3@xxxxxxxxx>, torios@xxxxxxxxxxxxxxxxxxx
Paul Sutton <zleap@xxxxxxxxxxx>
Wed, 15 May 2019 08:53:28 +0100
addr=zleap@xxxxxxxxxxx; keydata= mQINBFhySwUBEACwN0bpRaDa+/+K3cmt7uXqhM6iDrazubnTZG3lmsee/oEot1QtQ0ue22T3 eiE+77qjlH8h6THDdgQWa2gmAGRGoc1cdmdc+H0ycseEeUP3/tcGQj1kXeElclMQX3w/v4aM mPlAFo7vMhizxliR5uTfJjiZcmqgWEiNBE+vUpp+vlvMVbQHLTh9+1uil0W9gStcLP2N/gSC AxsvJu/X50F9nWlMYNmvJamJQ7OOqhy8nhkCzPM9r5ORkVETPfaqLFk675aklGaIzm38HMs/ gESbs4+96NJWTmM0UaW2Qal4FsVlbAKivzlNpZmGozvtb8xHBbskk29AcDUCo2vdYDKVddUc 2EZ8wQ88hNzj+0vNQlJc5adlNusGNqNOHF536w+Zj6dx1Xa5X+6gW56Eds3NXhJVBlxhvdXu U0/q21/FnrekvnfzUdXW4gCiAA3DRAammboC9hffa4KvXa78hIY4mZDEF/lxIK0QUtevESUx HYtD+0iHeYRfc/ReA0FIUXbalAK9tEW8kD+vGaeSrsJy7zOaiN8bGwcHGUFGAZgqrZlgWUIu G3gecPUVDRRcNroaew4lAxxkNqfvhFBAM+RnveMvE7GbSrtiQzAm46yZBJptaLO63lhtxSkE TPlN/SU8pMpWAdUmVQH35tX0w7jAfi4O5C/ECR4fWYmlB5XwtwARAQABtB9QYXVsIFN1dHRv biA8emxlYXBAZGlzcm9vdC5vcmc+iQJUBBMBCAA+FiEEfW22gvNRjQgYkx4W8IZVN9BmMC0F Alw4lLoCGyMFCQlmAYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQ8IZVN9BmMC1dAQ/8 DVPQ/BAINYg55yDk//aalNlbgMZszpIbV37ItSdrjiX+XvM14zpjM1nWVSZCcr+AXjWl1wl/ ufA5FIJEJy2AlO6w3NOzrJrD5RLUVpsmgR8xs9qfRlwd69r/E8gfX9xRy7htNzUTMcUL5N88 lyA3aqBQcjI7Uf/StVHaV+ZRx46snLVpqQPZOFT5FzftxTS6mjYoh3EOBdDK8QQaW0pu/PHN TNhZRdVtHVAGQKFHjTYmY7UvrdXCKBOYrDjej4vWWilGm4PlWcXQjvhlqVGOZGo5l0H12NPc mEiaWtYEwrREKtRv4vIW3x3L/l+sS3Ndj1QJtry+qfZ8fGx0kG0hXnq/CY0S1/xkoRAXCF6t hIwkiXYfjC/0ikbDCBMqcP2CGNGHgWb1FChezbYVsJdl9GK4dd3KI9CQ12cSMjLX9iOoSKhR D2XQ6d3bDCCGrS/owmAfiDtw52o1GXdbkxYV8d3MD8JLaJ0HBrwJfyxkyYf4uugVuE/R71JU p7we8qm63Ml3n/ogoF/xqtppXsLZxEUv3Vz0taOYOB2km7z4sTE60g/RlvOTyhQMaIQ/9Zmw CIYFgwvuN5ahAw9U3pB2+3/n+L2WCv2sI/d8p1yytvShB/finrtNmgtJUr79E5QSAlDEWpjY 2EPXMGDUUOCWjyak+osNmjABzNTABliPmDG5Ag0EWHJLBQEQAL2YMH+1Pq0tzQ5pS6LZlNm/ ng0oekTrkzocoCb6LzJxQ7lCaMRpCfwS0uqt1NGmfd9/dHVlV950mdyXw8fVy6eBPaNxd/NB vRDfmNkm9eU+5rfgnEKpKv0y+lT9hjMTHTZsiQK0BbwgHt0Nbr/9hyTlFeLnfiyIK1AmTGBn reAsiLFa/zkDkogV567Tv+KWadrsCjGFruE/hkfBETxMWRQWClxZpNGhGoppCPaUDPHVSotj 8WNZ2f9IsvhKA45UTL+i7YydffIT2/zO6MMDIVSeyzsCI+12comBzGaidBqljmo/KrTexJIc 51HzZSJtWKrA9oTsd0pym9TLBdZRim4Js8L35PK8K+ZqIcyDVz8gI03a3sjiANLc4BFYpcE+ ZHVu9psreTjjnXs+q3I6oDYFJFY26FpMdW8j7zcvkfo450Gfry9LsWiTRsPkhceSqUnK2ZDu 5JGg3p5pDbfQJzWl/xXFO9IK8Ws/DLcqtXYqbUrdN6cBXszIlRxtbXpffkMzn5Olha3i91RD KLLhZSmyL4NPwWIR+KxYwhQj8ren0c5ueXiyHtX2zmoj1tHlNa3rXAmsfPzxYTyCE4otGVnh dNwb47So4+zf/hz3rvDg14IhfZTl4F4PPSMoVMRmC3hZ5TZTmGHnO7rvxh3uSnDTwLo6gPq1 6cymsVRFaW9XABEBAAGJAiUEGAEIAA8FAlhySwUCGwwFCQlmAYAACgkQ8IZVN9BmMC1LYA// cRHDPiNdYnfbxpJrD1UAzW8uJ9Zg+7zmumo/yegOZnit+tRV/dvrA50e12Nv9cQlmsjqt0bH Rka/hp3laL7wIso9BHFGzbqFK544Wj89XFlVB33mj9Hw1Y6FOK1tki43e92/wgTqmuhNl8BY rR/aJ2JlUObi/mXYitPgtLOsn3cwNeldDhJf0s38uEVI0VEnRpQ44WlldxEPD+rKBGlHL2a3 1HBptSi7XV8Rs858l05zpM0YAc6CArj3EotOeGQUzMwprnzG2+mK5gobsvuwGK8DondN2KSr rdmMIF4K/aUrxQ6SgL59RjNRTM2KeA/bss9rufy/e9iijcvZIEpq5YLJptaAmCOghmYMG01B sckz+q9d5dTE9sbGTSVlLkIQYJ4fKIV2DxiIHBv18g5FOnioPTQ44yvBpAq21CDRoySlZxjq Qj+UprbgQayiG5OGeXzUkNyFwKajSsJe/lppbjn7M9SLK6oJTkwkbgQSSsCnUVWZ+7DbZdcJ 68atsqpEK050XUerZWVCAuJtR0+ziJUBke8iqi9XYVEKP1RwpwGOEMust6dc9gskgPAvI9do L92wbJ2C4D0+BJUYDWueKOXmTDxz45UEtLeFv4Z5b6Eul6kGC60MS5Q7gqbu1PDeVcYU5Dkp aPZ0K9hksQXvyArO2cFPbYZs3Bxgd8Me7m4=
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
Perhaps we need a clear - short, medium and long term road map for
ToriOS (like there is with Debian, so there is stable, testing and
unstable, which for the next release of debian would be buster, bullseye
and sid respectively.)
We then take a look at what we have now and what works, As ToriOS is
based on Jessie, where will our roadmap fit in with Debian releases.
Perhaps our next stable release should be based on Bullseye, so that is
a long term development plan, where as the current stable relesae
should migrate between Debian 9 to 10.
In terms of manuals, I would be up for splitting this in to
A general user manual (longer)
Install guide, which could double up docs for OBI too.
Developer guide (2 areas one for stable and one for the development release)
Testing guide so a short guide on how to install in a vm,how to submit
patches, bug reports etc.
Each of the above can then be presented in the most appropriate format.
That way also contributors are not trying to write one size fits all manual.
Maybe writing these docs will help us reflect on a roadmap.
I agree on sending contributions to the manual via e-mail, esp as i
using Overleaf and LaTeX, I can just drop in the changes.
On 14/05/2019 21:23, Momozor wrote:
> Or we could send and apply patches to the documention maintainer via email
> like in the linux kernel project. It is probably easier to manage because
> well, most people on the net usually have an email address at the very
> least and nobody have to register with a certain website to contribute the
> changes to the documentation repository.
> Both git and bzr support this kind of 'email patch' facility, and someone
> could write a script to automate the 90% process to abstract the tedious
> things and make it available for other people to use right away without
> dealing with the specific tool quirks, etc.
> On Tue, May 14, 2019, 2:40 PM Paul Sutton <zleap@xxxxxxxxxxx> wrote:
>> On 14/05/2019 00:01, ml@xxxxxxxxxxxx wrote:
>>> On Mon, May 13, 2019 12:23 am, Paul Sutton wrote:
>>>> lets discuss further and look at other examples, I am sure there were
>>>> links for this, I just posted the fedora one but I wonder if there are
>>>> other projects with similar tools,
>>> With the link you sent, took me a while to get to C/C++ programming and
>>> then all the projects that they mentioned weren't really of interest to
>>> me. If we do something like this, we should leave it more open-ended.
>>> Maybe someone has a great idea for volunteering that hasn't been
>>> categorized yet.
>>> We could also just create a simple page listing general categories/ideas
>>> where help is needed and ask users to join the list or e-mail to discuss
>>> further. Interactive can be very nice, but only if it can get
>>> to the reader that he/she wants. I've seen several projects that ask for
>>> help, but just don't have the follow through. Either they don't list
>>> enough areas of interest to satisfy everyone or don't tell you what to do
>>> to take the next step, get involved and get started. Some sites leave up
>>> old lists with items they no longer want help on. Also, with some
>>> projects, when you volunteer to help, they don't know what to do with the
>>> effort. One Open Source project asked for help. When I ported the code
>>> to another platform and offered to send them the patches, instead of
>>> saying thank you, they asked for it to work with a different compiler
>>> (which I don't even use). Some Linux distributions use volunteers and
>>> don't even thank them or sometimes throw out their efforts. I remember
>>> reading and following all the documentation on how to package something
>>> for a distribution and some packages they took and some they ignored
>>> because it didn't meet unwritten rules on how they wanted it packaged. I
>>> recently saw a distribution asking for help and for people to write
>>> applications for their system. When I asked what kind of applications
>>> they were looking for, they didn't even have an answer.
>>> If a project to recruit volunteers is going to work well, people involved
>>> should be open to listening to ideas, very clear about what steps a
>>> volunteer should take and what exactly needs to be done for the work to
>>> officially accepted and polite to the volunteer (for example: thank them
>>> for the effort).
>>> Sorry to go off on a bit of a tangent. I do believe it's the message
>>> that's most important not the medium. So, we can come up with a cool
>>> interactive example with all the latest web 2.0 bells and whistles, but
>>> it doesn't convey useful information to the reader, it won't be
>> Some really good points made here, Thank you. I think firstly we need to
>> be clear as to some preliminary skills required.
>> 1. Launchpad
>> 2. git / github along with bazaar / bzr
>> 3. e-mail
>> 4. Possibly IRC
>> Where we need help
>> 1. LaTeX / Overleaf
>> 2. Markdown
>> 3. Docbook
>> 4. wiki something
>> 5. Plain text
>> We can collaborate using Overleaf. If people sign up with my affiliate
>> link as normal users can have 1 collaborator, I can't afford to get a
>> higher level account at the moment this allows github integration and
>> more real time collaborators.
>> However once we start downloading the source files to collaborate via
>> git hub, then t gets really confusing as I would then need to upload
>> back to overleaf, to retain the work from anywhere. it would be better
>> in some ways for people to work on plain text files, and I can take
>> those, and replace text in the manual I am working on with the new text.
>> At the same tine those plain text files can be used with markdown and
>> other formatting systems.
>> The manual files are on github anyway.
>> Linked to this we need screenshots of different applications etc,
>> perhaps a install manual (which should really be part of the OBI docs or
>> link in with them),
>> JWM settings manager docs come under the JWM project, there is no point
>> in repeating the same information if one document can be references /
>> cited. It is also less to maintain longer term. So people writing JWM
>> docs would in effect write one document for two projects,
>> Screen shots can be taken as part of the testing process too.
>> Not sure what development languages we are using but lets take one
>> aspect of this at a time.
>> Just an idea
>> Paul Sutton
>> gnupg : 7D6D B682 F351 8D08 1893 1E16 F086 5537 D066 302D
>> Mailing list: https://launchpad.net/~torios
>> Post to : torios@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~torios
>> More help : https://help.launchpad.net/ListHelp
gnupg : 7D6D B682 F351 8D08 1893 1E16 F086 5537 D066 302D