Re: Google Summer of Docs proposal 2021
Sriram Ramkrishna <[email protected]> Mon, 15 Mar 2021 09:35:29 -0700
| Newsgroups | gmane.comp.gnome.documentation |
|---|---|
| Message-ID | <CADWtFE=s4BvqzSyeJ82pspN3HX4XkEUPhy8diX+nxz01ZAFJdQ@mail.gmail.com> |
--===============8271251700160062165== Content-Type: multipart/alternative; boundary="00000000000017894f05bd95d743" --00000000000017894f05bd95d743 Content-Type: text/plain; charset="UTF-8" Hi Andre! Great questions. I'll try to answer. On Mon, Mar 15, 2021 at 9:08 AM Andre Klapper <[email protected]> wrote: > Hi, > > On Mon, 2021-03-15 at 08:11 -0700, Sriram Ramkrishna wrote: > > I'm working on a GSoD for this year and I've outlined the proposal. I > > just wanted to give you all a heads up. I'm mostly focusing on our wiki > > and looking to remove everything updated, and update the ones that are > > still valid. But we will also use that experience to build a better > > onboarding experience by building a more supportable project > > documentation setup that can be managed for the future. > > > > If you have any thoughts, questions, or comments that would be > > appreciated. Here is the current proposal. > > > > https://etherpad.gnome.org/p/gsod-2021-proposal > > I'm trying to understand the scope and complexity of this. > > About how many pages are there to audit? > I don't know off hand. The first phase is to audit it to find the scope and then flag things for removal or flag for update. > Does "remove" mean deleting pages (and making URLs become 404s if you > don't manually [[REDIRECT]]), or 'only' removing content from pages? > Remove means archive in this case. I don't want to delete anything permanently - they are historical and in the case of projects might be useful either to be possibly revived or for historical context. There are some that just have wrong information altogether and hasn't been touched in many years. Those will either be updated or retired completely. > For the "work with community members", have those community members > committed to allocating sufficient resources? > I haven't secured any resources. In that particular case, when I say work with community members, I mean - asking the owner of that project - "is this information current or can I delete it" So the commitment is to answer questions about the utility of the content. Primarily I see my role here to make the introductions on how to talk to - eg I am the guide/map for stuff in the wiki. > "looking at alternative documentation technologies" means potentially > replacing the MoinMoin installation by moving stuff to Gitlab (or so)? > Yes. But that's part of an overall revamp of our web infrastructure. It's due for a major rehaul and so the two need to work together. > If it's about "building a better onboarding experience", is there an > analysis available what's bad about the current onboarding experience > with specific regard to the wiki? > Only the one analysis I did about two years ago when I went through them. There was enough wrong information that onboarding would have been confusing. I am not sure if I still have the etherpad where I had my notes there - but it was at our last combined hackfest with the docs team, engagement team and gtk team. That analysis/audit was only about 2 levels deep though. Part of what I want to do is also start focusing on keeping metrics - so a better onboarding experience also means measuring things better within the project. > If it's about "building a more supportable project documentation > setup", is there an analysis about the current pain points and how this > plays along in combination with documentation in other places such as > help.gnome.org, GitLab wiki pages, or GitLab README.md files? > I'm not aware of any analysis - the idea of this project is to do exactly that. The idea is we build a proposal and that proposal has to include the current pain points (otherwise how does it become better?) and then we need to convince ourselves that this is a good solution going forward. I think the current wiki setup has not been particularly good if not altogether ignored. Part of that problem is our own set of process, but the bulk of our information is moving into gitlab and maybe gitlab is the right answer, but it needs to be investigated. I don't think this is an easy project to do - especially when it comes down to consensus. That's why the project is focused on a proposal as the end result - not to implement but at least debate. Cheers, sri > Cheers, > andre > -- > Andre Klapper | [email protected] > https://blogs.gnome.org/aklapper/ > > > --00000000000017894f05bd95d743 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Hi Andre! Great questions. I'll try t= o answer.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D= "gmail_attr">On Mon, Mar 15, 2021 at 9:08 AM Andre Klapper <<a href=3D"m= ailto:[email protected]">[email protected]</a>> wrote:<br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex">Hi,<br> <br> On Mon, 2021-03-15 at 08:11 -0700, Sriram Ramkrishna wrote:<br> > I'm working on a GSoD for this year and I've outlined the prop= osal. I<br> > just wanted to give you all a heads up. I'm mostly focusing on our= wiki<br> > and looking to remove everything updated, and update the ones that are= <br> > still valid. But we will also use that experience to build a better<br= > > onboarding experience by building a more supportable project<br> > documentation setup that can be managed for the future.<br> ><br> > If you have any thoughts, questions, or comments that would be<br> > appreciated. Here is the current proposal.<br> ><br> > <a href=3D"https://etherpad.gnome.org/p/gsod-2021-proposal" rel=3D"nor= eferrer" target=3D"_blank">https://etherpad.gnome.org/p/gsod-2021-proposal<= /a><br> <br> I'm trying to understand the scope and complexity of this.<br> <br> About how many pages are there to audit?<br></blockquote><div><br></div><di= v>I don't know off hand. The first phase is to audit it to find the sco= pe and then flag things for removal or flag for update.</div><div> <br></di= v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= r-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Does "remove" mean deleting pages (and making URLs become 404s if= you<br> don't manually [[REDIRECT]]), or 'only' removing content from p= ages?<br></blockquote><div><br></div><div>Remove means archive in this case= . I don't want to delete anything permanently - they are historical and= in the case of projects might be useful either to be possibly revived or f= or historical context.</div><div><br></div><div>There are some that just ha= ve wrong information altogether and hasn't been touched in many years. = Those will either be updated or retired completely.</div><div><br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"> <br> For the "work with community members", have those community membe= rs<br> committed to allocating sufficient resources?<br></blockquote><div><br></di= v><div>I haven't secured any resources. In that particular case, when I= say work with community members, I mean - asking the owner of that project= - "is this information current or can I delete it" So the commit= ment is to answer questions about the utility of the content. Primarily I s= ee my role here to make the introductions on how to talk to - eg I am the g= uide/map for stuff in the wiki. <br></div><div> <br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> <br> "looking at alternative documentation technologies" means potenti= ally<br> replacing the MoinMoin installation by moving stuff to Gitlab (or so)?<br><= /blockquote><div><br></div><div>Yes. But that's part of an overall reva= mp of our web infrastructure. It's due for a major rehaul and so the tw= o need to work together. <br></div><div> <br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex"> <br> If it's about "building a better onboarding experience", is t= here an<br> analysis available what's bad about the current onboarding experience<b= r> with specific regard to the wiki?<br></blockquote><div><br></div><div>Only = the one analysis I did about two years ago when I went through them. There = was enough wrong information that onboarding would have been confusing. I a= m not sure if I still have the etherpad where I had my notes there - but it= was at our last combined hackfest with the docs team, engagement team and = gtk team. That analysis/audit was only about 2 levels deep though.</div><di= v><br> </div><div>Part of what I want to do is also start focusing on keepi= ng metrics - so a better onboarding experience also means measuring things = better within the project. <br></div><div><br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex"> <br> If it's about "building a more supportable project documentation<b= r> setup", is there an analysis about the current pain points and how thi= s<br> plays along in combination with documentation in other places such as<br> <a href=3D"http://help.gnome.org" rel=3D"noreferrer" target=3D"_blank">help= .gnome.org</a>, GitLab wiki pages, or GitLab README.md files?<br></blockquo= te><div><br></div><div>I'm not aware of any analysis - the idea of this= project is to do exactly that. The idea is we build a proposal and that pr= oposal has to include the current pain points (otherwise how does it become= better?) and then we need to convince ourselves that this is a good soluti= on going forward.</div><div><br></div><div>I think the current wiki setup h= as not been particularly good if not altogether ignored. Part of that probl= em is our own set of process, but the bulk of our information is moving int= o gitlab and maybe gitlab is the right answer, but it needs to be investiga= ted. I don't think this is an easy project to do - especially when it c= omes down to consensus. That's why the project is focused on a proposal= as the end result - not to implement but at least debate. <br></div><div><= br></div><div>Cheers,</div><div>sri<br></div><div> <br></div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= rgb(204,204,204);padding-left:1ex"> <br> Cheers,<br> andre<br> --<br> Andre Klapper=C2=A0=C2=A0|=C2=A0=C2=A0<a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a><br> <a href=3D"https://blogs.gnome.org/aklapper/" rel=3D"noreferrer" target=3D"= _blank">https://blogs.gnome.org/aklapper/</a><br> <br> <br> </blockquote></div></div> --00000000000017894f05bd95d743-- --===============8271251700160062165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gnome-doc-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-doc-list --===============8271251700160062165==--