torios team mailing list archive

[Momozor <skelic3@xxxxxxxxx>]

Hi.

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.

--
Sincerely,
Momozor

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
> two
> >> 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
> information
> > 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
> custom
> > 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
> be
> > 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
> if
> > it doesn't convey useful information to the reader, it won't be
> effective.
> >
> > Sincerely,
> > Laura
> >
> >
>
> 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
>
> Documentation
>
> 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
>
> --
> Paul Sutton
> http://www.zleap.net
> https://www.linkedin.com/in/zleap/
> 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
>