yes On 4/5/13 12:13 PM, "Michal Mocny" <[email protected]> wrote:
>Great point: down the road we will use ML search and that doesn't index >the >content of links to docs. > >Thus I concur its reasonable to discuss initial proposals and settling >direction on ML, and finally linking to a wiki/gdoc which summarizes the >conclusion. That doc can continue to make small churn on the details, but >new major shifts in direction should be a ML thread. > >Sound right? > >-Michal > > >On Fri, Apr 5, 2013 at 3:08 PM, Michael Brooks ><[email protected]>wrote: > >> > >> > My main problem is starting a proposal or draft on a website to begin >> > with. The initial discussion, in my mind, should be done on the list >>in >> > email form, so the apache archives have a clear record of how a >> discussion >> > about a new proposal or feature has evolved. >> >> >> This summaries that main concern. It's not being too lazy to click a >>link >> or communication of revisions. It's that in 5 years from now, the >>Cordova >> project will have lost and gained contributors, but the evolution of >>each >> proposal will still be accessible because it has been captured >> and archived by Apache's Infrastructure. >> >> >> >> >> On Fri, Apr 5, 2013 at 11:59 AM, Filip Maj <[email protected]> wrote: >> >> > My main problem is starting a proposal or draft on a website to begin >> > with. The initial discussion, in my mind, should be done on the list >>in >> > email form, so the apache archives have a clear record of how a >> discussion >> > about a new proposal or feature has evolved. >> > >> > So instead of "here's my proposal: link", it would be "here's my >> proposal: >> > text dump from the link" >> > >> > In terms of documenting the proposal as it evolves from the list, I >>don't >> > care whether it's in Gdocs or in the wiki. >> > >> > On 4/5/13 11:56 AM, "Michal Mocny" <[email protected]> wrote: >> > >> > >-1, but hey, what can you do.. >> > > >> > >I guess that if we don't like opening links, then we will be >>consuming >> > >wiki >> > >doc proposals via the wiki-update emails that go out? Also, since it >> > >emails for each patch, perhaps update the wiki with as few commits as >> > >possible, including when making comments, and ideally without causing >> edit >> > >conflicts with others editing. Shish, good luck. >> > > >> > >-Michal >> > > >> > >On Fri, Apr 5, 2013 at 2:36 PM, tommy-carlos Williams >> > ><[email protected]>wrote: >> > > >> > >> +1 >> > >> >> > >> Guiltily admitting to being in the not-opening boat with Fil :/ >> > >> >> > >> On 06/04/2013, at 4:22, Filip Maj <[email protected]> wrote: >> > >> >> > >> > +1, it's a bad excuse on my side but the extra step in opening >>the >> > >>link >> > >> is >> > >> > sometimes enough to discourage me from even looking at proposals >>:P >> > >> > >> > >> > On 4/5/13 10:18 AM, "Michael Brooks" <[email protected]> >> > wrote: >> > >> > >> > >> >> Hey guys, >> > >> >> >> > >> >> I know this has been on the minds of a number of contributors >>and I >> > >>want >> > >> >> to >> > >> >> bring it up on the list. >> > >> >> >> > >> >> I think we need to stop using Google Docs for drafting our >>plans, >> > >> >> specifications, and such. >> > >> >> >> > >> >> For myself, this is a little disappointing because I like Google >> Docs >> > >> and >> > >> >> I >> > >> >> think it's easy to comment and amend the document. However, the >> data >> > >>is >> > >> >> not >> > >> >> hosted by Apache Infrastructure and the changes are not >>captured on >> > >>the >> > >> >> source control, mailing list, issue tracker, or wiki. In other >> words, >> > >> it's >> > >> >> side stepping the regular channels that contributors would >>monitor. >> > >> >> >> > >> >> For future documents, we should be using the wiki. The wiki does >> > >>support >> > >> >> rendering comments [1], so we can achieve the same effect as >>Google >> > >> >> Docs... >> > >> >> just in a more awkward way. >> > >> >> >> > >> >> Thoughts? If someone can make a compelling case to keep using >> Google >> > >> Docs, >> > >> >> I'm all ears. >> > >> >> >> > >> >> Michael >> > >> >> >> > >> >> [1] http://wiki.apache.org/cordova/HelpOnComments >> > >> > >> > >> >> > >> > >>
