Fwd: [GSoC Mentors] Announcing Season of Docs 2019

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: [GSoC Mentors] Announcing Season of Docs 2019

kingcrimson
Nir,
Shall we apply? I think for example documenting liboctave API would be a great project ....
c.

Begin forwarded message:

From: "'sttaylor' via Google Summer of Code Mentors List" <[hidden email]>
Subject: [GSoC Mentors] Announcing Season of Docs 2019
Date: 11 March 2019 at 23:32:46 GMT+1
To: Google Summer of Code Mentors List <[hidden email]>
Reply-To: sttaylor <[hidden email]>

We’re delighted to announce the inaugural year of Season of Docs, a Google program that fosters collaboration between open source projects and technical writers. Season of Docs is similar to Summer of Code, but with a focus on open source documentation and technical writers. Details are on our website: g.co/seasonofdocs.


Would you like to take part as an open source mentor in the inaugural year of Season of Docs? Open source organizations can start thinking now about the projects you’d like a technical writer to work on. Take a look at the examples of project ideas. Reach out to your community members to see who’d like to be a mentor for Season of Docs. As a mentor, you don’t need technical writing skills. Instead, you're a member of the open source organization who knows the value of good documentation and who is experienced in open source processes and tools. See the guidelines on working with a technical writer. Organization applications open on April 2, 2019. See the full timeline on the Season of Docs website.


From April 30, Technical writers can explore the list of participating open source organizations and their project ideas. Technical writers bring their skills in designing and developing documentation to the open source organization. Technical writer applications open on April 30. The list of accepted technical writing projects is announced on July 30.


Please do tweet and blog about Season of Docs if you’d like to share the news. We want as many people to know about it as possible. We’ve provided logos that you can download and some example content on the press page.


We’re looking forward to an exciting pilot of the Season of Docs program!


If you have any questions about the program, please email us at [hidden email].


Best regards

Sarah Maddox, Andrew Chen and the Season of Docs team


--
You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/google-summer-of-code-mentors-list.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/563595bc-e36d-411e-9868-71a5f75742a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Reply | Threaded
Open this post in threaded view
|

Re: [GSoC Mentors] Announcing Season of Docs 2019

nrjank
On Tue, Mar 12, 2019, 6:32 AM c. <[hidden email]> wrote:
Nir,
Shall we apply? I think for example documenting liboctave API would be a great project ....
c.


Can't hurt to apply.  Compared to other programs Octave's documentation is pretty extensive. Are there other areas its known to be deficient?  Anything applicable to new users or would-be developers? 

Worth a separate section of the wiki to collect suggestions?

Reply | Threaded
Open this post in threaded view
|

Re: [GSoC Mentors] Announcing Season of Docs 2019

Nir Krakauer-3
Carlo,

I am in favor. Would you like to lead it? You can adapt the GSoC application materials from https://wiki.octave.org/GSoC_2019_application

> Worth a separate section of the wiki to collect suggestions?

Yes, either a separate page or a section of the GSoC ideas page.

--Nir
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC Mentors] Announcing Season of Docs 2019

Rik-4
In reply to this post by kingcrimson
On 03/12/2019 05:16 AM, [hidden email] wrote:
Subject:
Re: [GSoC Mentors] Announcing Season of Docs 2019
From:
Nicholas Jankowski [hidden email]
Date:
03/12/2019 05:04 AM
To:
Carlo de Falco [hidden email]
CC:
octave maintainers mailing list [hidden email], Nir Krakauer [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="0000000000003896700583e47f68"
Message:
3

On Tue, Mar 12, 2019, 6:32 AM c. <[hidden email]> wrote:
Nir,
Shall we apply? I think for example documenting liboctave API would be a great project ....
c.


Can't hurt to apply.  Compared to other programs Octave's documentation is pretty extensive. Are there other areas its known to be deficient?

Absolutely.  We don't have comprehensive documentation of the classdef interface.  The old @class format *is* documented, but hardly anyone uses that.

I'd like to see the documentation that describes the visual functions all have at least one example image.  For example, the colormaps are described in words, but that is really no help at all.  You need to see what a colormap looks like.  An easy thing to do would be to run the colormap demo #1 and display that image in the documentation.  That might be more of a coding project, than a technical writer's project though.

I'd like to see separate documentation for plot markers and line styles so that something like "help linestyle" would return something.  And then I'd like the graphics documentation reviewed and cross-references to this documentation place in the manual.  Currently, we often say something like "See @code{plot} for a description of marker and line styles".

Also, if you use the selection tool on the Savannah bug tracker you can find a fair number of bugs that are just about documentation.  They often just need someone to write up text that is clear as to a function's purpose and method of use.

Anything applicable to new users or would-be developers? 

Worth a separate section of the wiki to collect suggestions?

Possibly, but also look on the bug tracker.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC Mentors] Announcing Season of Docs 2019

John W. Eaton
Administrator
On 3/12/19 11:31 AM, Rik wrote:

> Absolutely.  We don't have comprehensive documentation of the classdef
> interface.  The old @class format *is* documented, but hardly anyone
> uses that.
>
> I'd like to see the documentation that describes the visual functions
> all have at least one example image.  For example, the colormaps are
> described in words, but that is really no help at all.  You need to see
> what a colormap looks like.  An easy thing to do would be to run the
> colormap demo #1 and display that image in the documentation.  That
> might be more of a coding project, than a technical writer's project though.
>
> I'd like to see separate documentation for plot markers and line styles
> so that something like "help linestyle" would return something.  And
> then I'd like the graphics documentation reviewed and cross-references
> to this documentation place in the manual. Currently, we often say
> something like "See @code{plot} for a description of marker and line
> styles".

All of these things would be great to have.  We must be sure that any
contributor is not plagiarizing Matlab docs.

If we have someone working on liboctave documentation, then we probably
want to be sure they are documenting interfaces that we really want to
keep.  So part of this work might also be to determine whether the
interfaces are "good".

jwe

Reply | Threaded
Open this post in threaded view
|

Re: [GSoC Mentors] Announcing Season of Docs 2019

Carnë Draug
In reply to this post by nrjank
On Tue, 12 Mar 2019 at 12:40, Nicholas Jankowski <[hidden email]> wrote:
>
> On Tue, Mar 12, 2019, 6:32 AM c. <[hidden email]> wrote:
>>
>> Nir,
>> Shall we apply? I think for example documenting liboctave API would be a great project ....
>> c.
>>
>
> Can't hurt to apply.

I contest this.  It is work to prepare the application, to review
candidates and their proposals, to guide and mentor those who do get
accepted, and finally to review and and merge their work.

Do apply, I'm just pointing out what may be required afterwards.