diff --git a/.build_package.R b/.build_package.R
index 47c892c8bb7300372f9d2142ff465c07935705ef..96db031ee97ff1c51a10fa14194d71d362eb0fc8 100755
--- a/.build_package.R
+++ b/.build_package.R
@@ -41,6 +41,13 @@ if (cp > 0) {
     check_doc()
 }
 
+#--------------------------------------------
+# Gerar as vinhetas, caso existam.
+
+if (length(list.files("./vignettes"))) {
+    build_vignettes(dependencies = FALSE)
+}
+
 #--------------------------------------------
 # Checar conteúdo e organização do pacote.
 
@@ -49,13 +56,6 @@ check(cleanup = FALSE,
       vignettes = FALSE,
       check_dir = "../")
 
-#--------------------------------------------
-# Gerar as vinhetas, caso existam.
-
-if (length(list.files("./vignettes"))) {
-    build_vignettes()
-}
-
 #--------------------------------------------
 # Construir pacote.
 
@@ -64,6 +64,8 @@ build(manual = TRUE, vignettes = TRUE)
 #--------------------------------------------
 # Instalar o pacote.
 
+rm(list = ls())
+
 lib <- path.expand("~/R-test/")
 dir.create(lib)
 .libPaths(new = lib)
@@ -73,4 +75,4 @@ install()
 
 unlink(lib, recursive = TRUE)
 
-#--------------------------------------------
+#--------------------------------------------
\ No newline at end of file
diff --git a/.gitignore b/.gitignore
index 7a42b35d19d7cf0d9ee75f8ce0db4f07c211b413..365ac7104700bd8fecb592c2f8fc2bc03f47d9eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,5 +16,5 @@ STYLEGUIDE.html
 roteiro.R
 inst/doc
 plano.Rmd
-
-
+vignettes/*.html
+!vignettes/Mathjax.html
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b42cfa070807179f3d96ee5868e2a2c2d9a3e9ed..bf615bbcbe82cec38e7823727cfa78ff9a982628 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -8,62 +8,117 @@
 >
 >> -- Mark Twain
 
+<!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-generate-toc again -->
+**Tabela de Conteúdo**
+
+  1. [Para que serve um Guia de Contribuição?](#para-que-serve-um-guia-de-contribuio)
+  1. [Qual é o Guia de Estilo de Código?](#qual--o-guia-de-estilo-de-cdigo)
+  1. [Qual é o fluxo de trabalho do *labestData*?](#qual--o-fluxo-de-trabalho-do-labestdata)
+  1. [Como dar nome aos datasets?](#como-dar-nome-aos-datasets)
+  1. [Como dar nome para as variáveis no `data.frame`?](#como-dar-nome-para-as-variveis-no-dataframe)
+  1. [Como declarar dados que não sejam tabelas?](#como-declarar-dados-que-no-sejam-tabelas)
+  1. [Que tipo de valor usar para as variáveis?](#que-tipo-de-valor-usar-para-as-variveis)
+  1. [O que colocar na documentação?](#o-que-colocar-na-documentao)
+  1. [Como dar nomes as vinhetas?](#como-dar-nomes-as-vinhetas)
+  1. [Como habilitar no `DESCRIPTION`](#como-habilitar-no-description)
+  1. [Como criar um *issue*?](#como-criar-um-issue)
+  1. [Quanto de trabalho representa um *issue*?](#quanto-de-trabalho-representa-um-issue)
+  1. [Como fechar ou editar um *issue*](#como-fechar-ou-editar-um-issue)
+  1. [Como fazer mensagens de *commit*?](#como-fazer-mensagens-de-commit)
+  1. [Como criar um *merge request*?](#como-criar-um-merge-request)
+  1. [Quais as exigências para aceitar um *MR*?](#quais-as-exigncias-para-aceitar-um-mr)
+  1. [Existe um *checklist* para incluir um *dataset*?](#existe-um-checklist-para-incluir-um-dataset)
+  1. [Existe um *checklist* antes de submeter um MR?](#existe-um-checklist-antes-de-submeter-um-mr)
+
+<!-- markdown-toc end -->
+
 ## Para que serve um Guia de Contribuição? ##
 
 O Guia de Contribuição serve para orientar a forma de trabalhar, tanto
 individual quanto em equipe, para que seja eficiente, padronizada,
 coordenada e segura. Ele estabelece as regras e etapas principais do
 desenvolvimento de um projeto. O Guia de Contribuição incluí orientações
-de como escrever o código, mensagens de commit, etc TODO
+de como escrever o código, as mensagens de *commit*, criar arquivos,
+etc.
 
 Interessados em participar do projeto devem se orientar pelo Guia de
-Contribuição sobre como o desenvolvimento acontece, das tarefas às
-responsabilidades dos indivíduos e equipes, das etapas e prazos aos
-resultados do projeto.
+Contribuição sobre como o desenvolvimento acontece, pois ele contém a
+documentação sobre a realização das tarefas, as responsabilidades dos
+indivíduos e equipes, as etapas e prazos para atingir as metas do
+projeto.
 
-## O que é um fluxo de trabalho? ##
+## Qual é o Guia de Estilo de Código? ##
 
-O fluxo de trabalho é a sequência de etapas que devem ser cumpridas para
-atingir um resultado.
+Um Guia de Estilo de Código é um conjunto de recomendações (ou regras)
+para padronizar a forma de escrever código. Códigos que são escritos
+seguindo um estilo padrão são mais fáceis de manter, modificar e
+garantir que estão corretamente escritos e funcionais, principalmente
+quando muitos programadores estão envolvidos.
+
+Quase todas as linguagem de programação permitem que os usuários adotem
+diferentes padrões de escrita de código.  Algumas não diferenciam
+maiúsculas e outras não exigem indentação, por exemplo. Em função de
+simplicidade, comodismo ou inércia na hora de escrever ou por causa de
+características da linguagem ou do editor usado, os usuários quase
+sempre tem um padrão particular para escrita de código.
+
+No pacote *labestData* deve ser considerado o *"idioma"* padrão do R,
+descrito no [STYLEGUIDE.md](STYLEGUIDE.md). Nesse arquivo é descrito
+desde como nomear objetos até o uso de espaço ao redor dos operadores.
 
 ## Qual é o fluxo de trabalho do *labestData*? ##
 
+O fluxo de trabalho é a sequência de etapas que devem ser cumpridas para
+atingir um resultado. No *labestData*, o fluxo de trabalho tem unidade
+semanal de desenvolvimento e acompanhamento.
+
 **Descrição do roteiro semanal**
 
   1. Criar um *issue* para o Projeto no GitLab. Ao criar o *issue*,
      dedique-se para escrever uma detalhada descrição do trabalho a ser
      feito. Isso informa a equipe sobre onde você irá trabalhar para que
-     não se dublique os esforços. Todo issue tem um número associado,
-     como `#7` e isso deve ser usado nas comunicações.
-  2. Faça uma atualização do seu ramo `devel` local com o ramo `devel`
-     do projeto no GitLab (atualize o HEAD). Isso pode ser feito com o
-     comando `git pull` ou com `git fetch + git merge`. Em caso de
-     insegurança, visite a
+     não se duplique os esforços. Todo *issue* tem um número associado,
+     como `#7` e isso deve ser usado nas comunicações. O GitLab cria
+     links para os *issues* automaticamente nas mensagens quando se
+     escreve o número precedido de #, como `#7`.
+  2. Faça uma atualização do seu ramo `baby` local com o ramo `baby`
+     remoto do projeto no GitLab (atualize o HEAD). Quando você executa
+     o comando `git branch -a`, aqueles precedidos de `remote/` são os
+     remotos. Isso pode ser feito com o comando `git fetch origin baby`
+     que atualiza o `remotes/origin/baby` seguido de `git merge
+     origin/baby` para passar do remoto para o local o conteúdo
+     trazido. O comando `git pull origin baby` executa as duas ações em
+     um único comando. Em caso de insegurança, visite a
      [Apostila de Git do PET Estatística](https://gitlab.c3sl.ufpr.br/pet-estatistica/apostila-git/raw/devel/apostila_git.pdf).
-  3. Crie um *branch* para começar o trabalho que você descreveu no
-     *issue* que acabou de criar. O nome do ramo deve ser formado pelo
-     seu nome e número identificador, como `angela23` e
+  3. Crie um *branch*, a partir do `baby`, para começar o trabalho que
+     você descreveu no *issue* que acabou de criar no GitLab. O nome do
+     ramo deve ser formado pelo seu nome e número identificador, aquele
+     atribuído ao *issue* assim que ele foi criado, como `angela23` e
      `eduardo31`. Usar esse padrão facilita para os membros descobrirem
-     do se se trata esse *branch*, pois basta consultar o *issue* de
+     do que se trata esse *branch*, pois basta consultar o *issue* de
      mesmo número, e quem é o responsável pelo mesmo.
   4. Faça o trabalho que descreveu. Nessa etapa você senta na frente do
-     computador e escreve e isso envolve os seguintes passos:
-     1. Escreve, corrija, aperfeiçoe, amplie, revise, organize, limpe,
-        etc. Faça o trabalho.
+     computador e desenvolve o seu trabalho que, envolve os seguintes
+     passos:
+     1. Escrever, corrigir, aperfeiçoar, ampliar, revisar, organizar,
+        limpar, etc. Fazer o trabalho.
      2. Faça *commits* com regularidade, de preferência, por unidades de
         trabalho para as quais se tem um significado claro - uma unidade
         de trabalho comitável - que possa ser expresso sem prejuízo por
         uma frase curta ou por uma lista de frases curtas. Quando não
         souber se já possuí uma unidade de trabalho merecedora de
-        *commit*, faça o *commit* do mesmo jeito. Não seja precioso com
-        isso. No entanto, seja caprichoso ao fazer a sua mensagem de
-        *commit* para garentir que esteja em conformidade com o guia de
-        boas práticas.
+        *commit*, faça o *commit* do mesmo jeito. Não seja conservador
+        com a quantidade de *commits*. No entanto, seja caprichoso ao
+        fazer a sua mensagem de *commit* para garantir que esteja em
+        conformidade com o guia de boas práticas.
      3. Em intervalos maiores, mas ainda com frequência, suba seu
-        trabalho para o repositório. Isso se faz com o comando `git
-        push`. É importante fazer sempre para evitar de perder o
-        trabalho da sua máquina que está sujeita a avaria.
-  6. Quando cumprir com o trabalho previsto no seu *issue*, dê o push
+        trabalho para o repositório. Isso se faz com o comando `git push
+        origin fulano00`, em que `fulano00` representa o seu *issue*. É
+        importante fazer *pushs* sempre para evitar de perder o
+        trabalho, já que a sua máquina que está sujeita a avaria, e
+        mostrar trabalho, uma vez que isso estimula os demais a fazerem
+        o mesmo.
+  6. Quando cumprir com o trabalho previsto no seu *issue*, dê o *push*
      final e faça uma requisição de mescla - um *merge request* (MR). Ao
      criar o MR, assim como foi para o *issue*, existe um espaço para a
      descrição de tudo o que foi realizado no *branch*. Basicamente isso
@@ -71,178 +126,180 @@ atingir um resultado.
      *issue* informe o que estava previsto fazer, isso não significa que
      tudo foi feito. Você pode ter feito trabalho a mais, ou visto que
      algo não foi necessário. Então relate na descrição do MR exatamente
-     o que será adicionado ao ramo alvo. Os MR devem ser para o ramo
-     `devel` e devem ser atribuídos à outra pessoa.
-  7. Aguarde a avaliação do MR. Nessa etapa quem trabalha é o *merger* -
-     colaborador  responsável por  avaliar o  seu *branch*  e aplicar  o
-     *merge*. Em caso de aprovação, o *merge* será aplicado. Em caso
-     contrário, você será notificado.
+     o que será adicionado ao *branch* alvo. Os MR devem ser para o
+     *branch* `devel` e devem ser atribuídos aos *mergers* do projeto
+     (pessoas responsáveis por fazer as inspeções e merge).
+  7. Aguarde a avaliação do MR. Nessa etapa quem trabalha é o
+     *merger*. Em caso de aprovação, o *merge* será aplicado. Em caso
+     contrário, você será notificado a fazer alterações (correções ou
+     adições).
   8. Se o MR não foi aceito, o *merger* vai informar o que fazer com
      mensagem abaixo da descrição do merge. Faça as adequações
-     solicitadas. Refaça a etapa 4.
+     solicitadas. Volte para a etapa 4.
   9. Quando o MR for aprovado, feche o *issue* correspondente. Indique
      na mensagem de fechamento do *issue* qual foi o número do MR
-     dele. Os ramos de demanda - com prefixo *coloborador* - são removidos
-     após o *merge* mas os *issues* e os MR - que junto com os *commits*
-     contam a trajetória do projeto - permanem no GitLab.
+     dele. Os ramos de demanda - com prefixo de nome de *colaborador* -
+     são removidos após o *merge* mas os *issues* e os MR - que junto
+     com os *commits* contam a trajetória do projeto - permanecem no
+     GitLab.
 
 **Guia de códigos R e GIT para as atividades semanais**
 
-A cada semana nós devemos criar novos ramos para realização das
-atividades propostas. Porém devemos nos atentar ao criá-los. Estes ramos
-devem necessariamente sair do ramo `devel` e não é necessário a
-incorporação do ramo de trabalho anterior (solicitado por MR) para que
-este seja criado. Abaixo temos os comandos GIT para criar o ramo a
-partir do `devel`.
+A cada semana devem ser criados novos ramos para realização das
+atividades propostas. Porém deve-se ter atenção ao criá-los. Estes ramos
+devem necessariamente sair do ramo `baby`. O ramo `baby` contém apenas
+um conjunto de dados para que adicionar os novos, seja mais fácil
+revisar as contribuições.
+
+Não é necessário que o ramo de trabalho anterior tenha sido incorporado
+ao devel, ou seja, para criar o `fulano2` não precisa ter o `fulano1`
+incorporado ao `devel`. Abaixo temos os comandos Git para criar o ramo a
+partir do `baby`.
 
 ```bash
-## Atualiza todos os ramos com a versão do servidor
-git pull
+# Retorna para o ramo baby (move o HEAD)
+git checkout baby
 
-## Retorna para o ramo devel
-git checkout devel
+# Atualiza o ramo baby com a versão do servidor
+git pull origin baby
 
-## Cria um ramo para atividades propostas no issue00
+# Cria um ramo para desenvolver as atividades propostas no issue00
 git branch fulano00
 
-## Vai para o ramo criado
+# Vai para o ramo criado (mode o HEAD)
 git checkout fulano00
-
 ```
 
 Com isso já estamos em um ramo, `fulano00` criado especificamente para o
-desenvolvimento das atividades propostas no `issue#00`, assim podemos
-prosseguir com o trabalho propriamente dito, a adição de conjunto de
-dados.
+desenvolvimento das atividades propostas no `issue #00`, assim podemos
+prosseguir com o trabalho propriamente dito, a adição de conjuntos de
+dados. Note que o ramo saiu do `baby`.
 
 ```r
-##======================================================================
-## Passo 1 - Ler e inserir os dados na pasta ./data-raw/
+#=======================================================================
+# Passo 1 - Ler e inserir os dados na pasta ./data-raw/
+
+# Usando o R -----------------------------------------------------------
 
-## Usando o R ----------------------------------------------------------
+# Transcreva os dados das tabelas
+CiclanoTb0.0 <- expand.grid(X1 = 1:6, X2 = LETTERS[1:4])
+CiclanoTb0.0$X3 <- scan()
 
-## Transcreva os dados das tabelas
-ex <- expand.grid(X1 = 1:6, X2 = LETTERS[1:4])
-x3 <- scan()
-CiclanoTb0.0 <- data.frame(X1 = ex$X1, X2 = ex$X2, X3 = x3)
+# Ou faça
+CiclanoTb0.0 <- expand.grid(X1 = 1:6, X2 = LETTERS[1:4], X3 = 0)
+CiclanoTb0.0 <- edit(CiclanoTb0.0)
 
-## Salve a tabela em formato txt no diretório ./data-raw/
+# Salve a tabela em formato txt no diretório ./data-raw/
 write.table(CiclanoTb0.0,
             file = "./data-raw/CiclanoTb0.0.txt",
             sep = "\t",
+            quote = FALSE,
             row.names = FALSE)
 
-## Você pode usar a função write2txt() definida em:
-## https://gitlab.c3sl.ufpr.br/snippets/34.
+# Você pode usar a função write2txt() definida em:
+# https://gitlab.c3sl.ufpr.br/snippets/34.
+
 write2txt(CiclanoTb0.0)
 
-## Usando outro software -----------------------------------------------
+# Usando outro software ------------------------------------------------
 
-## Transcreva os dados da tabela no software e salve-os no formato txt
-## na pasta ./data-raw/
+# Transcreva os dados da tabela no software e salve-os no formato txt
+# na pasta ./data-raw/
 
-## Leia os dados na sessão R, para utilizá-los posteriormente
+# Leia os dados na sessão R, para utilizá-los posteriormente
 CiclanoTb0.0 <- read.table("./data-raw/CiclanoTb0.0.txt",
                            header = TRUE, sep = "\t")
 
-##======================================================================
-## Passo 2 - Inserir os dados no diretório ./data/
+#=======================================================================
+# Passo 2 - Inserir os dados no diretório ./data/
+
 library(devtools)
 use_data(CiclanoTb0.0)
 
-## Você pode usar a função write2rda() definida em:
-## https://gitlab.c3sl.ufpr.br/snippets/34.
+# Você pode usar a função write2rda() definida em:
+# https://gitlab.c3sl.ufpr.br/snippets/34.
+
 write2rda(CiclanoTb0.0)
 
-##======================================================================
-## Passo 3 - Escreva a documentação utilizando as tags roxygen2
+#=======================================================================
+# Passo 3 - Escreva a documentação utilizando as tags roxygen2
 
-## Dica: rode os códigos da sessão exemplo aqui, para verificar se os
-## gráficos/tabelas são realizadas corretamente.
-table(CiclanoTb0.0)
+# Dica: prepare os códigos da sessão exemplo aqui, para verificar se os
+# gráficos/tabelas são produzidos corretamente
+
+xtabs(~X1, CiclanoTb0.0)
 plot(X1 ~ X2, data = CiclanoTb0.0)
 
-## Você pode usar a função write2Rdoc() definida em:
-## https://gitlab.c3sl.ufpr.br/snippets/34. Essa função cria o arquivo
-## com nome do objeto e algumas já escreve algumas informações,
-## retiradas do próprio objeto. Depois de usar, abra o arquivo e
-## preencha o restante.
+# Você pode usar a função write2Rdoc() definida em:
+# https://gitlab.c3sl.ufpr.br/snippets/34. Essa função cria o arquivo
+# com nome do objeto e já escreve algumas informações, retiradas do
+# próprio objeto. Depois de usar, abra o arquivo e preencha o restante.
+
 write2Rdoc(CiclanoTb0.0)
 
-##======================================================================
-## Passo 4 - Gere e check a documentação (insere um arquivo no diretório
-## ./man/). Obs.: O aviso sobre o NAMESPACE pode ser ignorado, pois o
-## document() tenta criar um NAMESPACE onde já há um existente, mas isso
-## não é problema pois ambos são arquivos sem conteúdo relevante.
+#=======================================================================
+# Passo 4 - Gere e check a documentação (insere um arquivo no diretório
+# ./man/). Obs.: O houver aviso sobre o NAMESPACE não ter sido feito
+# pelo roxygen2, delete o arquivo para que ele seja contruído novamente.
+
+file.remove("NAMESPACE")
+
 document()
 check_man()
 
-##======================================================================
-## Passo 5 - Verifique a constituição e organização do pacote (caso haja
-## ERROS, WARNINGS ou mais de um NOTE. Corrija o problema e continue do
-## passo 4)
+#=======================================================================
+# Passo 5 - Verifique a constituição e organização do pacote. Caso
+# apareçam sinais de ERROR, WARNING ou NOTE, procure eliminar esses
+# sinais.
+
 check()
 
 ```
 
 Após todos os passos concluídos devemos ter os arquivos `.txt`, `.rda`,
-`.R` e `.Rd` devidamente criados. Podemos voltar ao terminal e *comitar*
-nossas contribuições.
+`.R` e `.Rd` devidamente criados. Podemos voltar ao terminal e comitar
+essas contribuições.
 
 ```bash
-## Adiciona os 4 arquivos criados e commita as alterações
-git add data-raw/. data/. R/. man/CiclanoTb0.0
+# Adiciona os 4 arquivos criados e commita as alterações
+git add data-raw/CiclanoTb0.0.txt data/CiclanoTb0.0.rda
+git add R/CiclanoTb0.0.R man/CiclanoTb0.0.Rd
 git commit -m "Adiciona tabela 0.0 do livro do Ciclano"
 
-## Desconsidera as alterações realizadas nos arquivos que são gerados
-## automaticamente
-git checkout .
+# Desconsidera as alterações realizadas nos arquivos que são gerados
+# automaticamente
+git checkout -- .
 
-## Enviando as alterações para o servidor
-git push origin fulano00
+# Limpe o seu diretório removendo os arquivos não rastreados.
+git clean -xfd
 
+# Enviando as alterações para o servidor
+git push origin fulano00
 ```
 
-Agora com tudo *commitado* podemos seguir para o próximo conjunto de
+Agora com tudo comitado podemos seguir para o próximo conjunto de
 dados e refazer todos os passos descritos.
 
 Vale ressaltar que este guia de códigos compreende a rotina básica para
 inclusão de um conjunto de dados, se for necessária a inclusão de um
 biblioteca para elaboração de gráficos ou análises ou ainda forem
 criadas funções para o pacote os arquivos NAMESPACE e DESCRIPTION
-deverão ser alterados e essas alterações *commitadas*.
-
-## O que é um Guia de Estilo de Código? ##
-
-Um Guia de Estilo de Código é um conjunto de recomendações (ou regras)
-para padronizar a forma de escrever código.  Códigos que são escritos
-seguindo um estilo padrão são mais fáceis de manter, modificar e
-garantir que estão corretamente escritos e funcionais, principalmente
-quando muitos programadores estão envolvidos.
-
-Quase todas as linguagem de programação permitem que os usuários adotem
-diferentes padrões de escrita de código.  Algumas não diferenciam
-maiúsculas e outras não exigem indentação, por exemplo. Em função de
-simplicidade, comodismo ou inércia na hora de escrever ou de
-características da linguagem ou do editor, os usuários quase sempre tem
-padrão particular para escrita de código.
-
-## Qual o guia de estilo de código? ##
-
-No pacote *labestData* deve ser considerado o *"idioma"* padrão do R,
-descrito no [STYLEGUIDE.md].
+deverão ser alterados e essas alterações comitadas. Veja a seção
+[Como habilitar no DESCRIPTION](#como-habilitar-no-description) como
+adicionar declarar o uso de pacotes.
 
 ## Como dar nome aos datasets? ##
 
 No caso de datasets de livros (obras impressas), o nome do dataset é
-formado pelo sobrenome do primeiro autor seguido da indentificação da
-tabela na obra. Considera os exemplos
+formado pelo sobrenome do primeiro autor seguido da indentificação do
+conjunto de dados na obra. Os exemplos abaixo ilustram variações dessa
+regra.
 
   * ZimmermannTb8.2: Tabela 8.2 do Zimmermann (2004);
   * RamalhoTb4.3: Tabela 3 do capítulo 4 em Ramalho, Ferreira e Oliveira
     (2005). Nesse livro as tabelas tem numeração reiniciada em todo
     capítulo e por isso adiciona-se o numeral do capítulo para evitar
-    ambiguidade, já que vários capítulos podem ter a tabela 1.
+    ambiguidade, já que vários capítulos certamente tem a tabela 1.
   * BanzattoQd3.6.1: Quadro 3.6.1 do Banzatto e Kronka (2013). Este
     livro usa o nome quadro ao invés de tabela.
   * DiasEx10.7: Exercício 7 do capítulo 10 em Dias e Barros (2009). Os
@@ -263,44 +320,181 @@ tabela na obra. Considera os exemplos
 
 A prioridade na hora de atribuir a identificação é a seguinte: Tabela =
 Quadro > Exemplo = Exercício > Página. Ou seja, se a tabela 5 faz parte
-do exemplo 3 que está na página 122, o nome do dataset terá sulfixo
+do exemplo 3 que está na página 122, o nome do dataset terá sufixo
 Tb5. Note que uma página pode ter mais de uma tabela, bem como um
 exemplo. Além do mais, diferentes edições podem preservar com mais
 facilidade a numeração das tabelas do que a localização delas nas mesmas
-páginas. Sendo assim, um dataset só será identificado como sulfixo Ex ou
+páginas. Sendo assim, um dataset só será identificado como sufixo Ex ou
 Eg se não tiver legenda (Tabela ou Quadro) e só será identificado pela
 página se não houver outra alternativa.
 
-## Como formatar as variáveis? ##
+A tabela abaixo resume as siglas usadas para cada tipo de referência ao
+conjunto de dados dentro da obra.
+
+| Referência | Abreviação |
+|------------+------------|
+| Tabela     | Tb         |
+| Quadro     | Qd         |
+| Exercício  | Ex         |
+| Exemplo    | Eg         |
+| Apêndice   | Ap         |
+| Página     | Pg         |
+
+Dados em artigos devem usar o nome do primeiro autor, mas esteja atento
+às recomendações a seguir:
+
+  * Se do artigo for usado apenas uma tabela de dados, não há
+    necessidade de colocar referência e contador no nome, ou seja, basta
+    `Fulano` ao invés de `FulanoTb1`.
+  * Se do artigo for usado mais de uma tabela, deve-se usar um
+    contador. Nesse caso seria `Fulano1` e `Fulano2`.
+  * No caso de dados de artigos diferentes que tenham o primeiro com
+    mesmo sobrenome, para distingui-las deve-se usar o ano logo após o
+    sobrenome do primeiro autor.
+
+Dados de arquivos pessoais que não foram usados em uma publicação
+(artigo, trabalho de conclusão de curso, dissertação ou tese), poder ter
+o nome do proprietário, do local de origem, ou outro identificador que
+seja único que descritivo do dataset.
+
+## Como dar nome para as variáveis no `data.frame`? ##
 
 O nome das variáveis não deve conter acentos (ASCII pleno), não pode
 iniciar com número e só admite o underline como não alfanumérico. As
-variáveis de nome composto e longo poder ser representadas por siglas, e
+variáveis de nome composto e longo podem ser representadas por siglas, e
 as de nome simples mas longo, por abreviação. Veja a tabela com
 exemplos.
 
-| Variável resposta         | Nome da coluna |
-|---------------------------|----------------|
-| Dias                      | dias           |
-| Idade                     | idade          |
-| Renda                     | renda          |
-| Produtividade             | prod           |
-| Temperatura               | temp           |
-| Pressão sanguínea         | ps             |
-| Massa seca de parte aérea | mspa           |
+| Variável                   | Nome da coluna |
+|----------------------------+----------------|
+| Dias                       | dias           |
+| Peso                       | peso           |
+| Idade                      | idade          |
+| Renda                      | renda          |
+| Cultivar                   | cult           |
+| Variedade                  | varied         |
+| Adubação                   | adub           |
+| Produtividade              | prod           |
+| Temperatura                | temp           |
+| Pressão sanguínea          | ps             |
+| Massa seca de parte aérea  | mspa           |
+| Diâmetro à altura do peito | dap            |
+
+## Como declarar dados que não sejam tabelas? ##
+
+Existem casos em que os dados não são uma tabela (várias variáveis, em
+cada coluna uma variável de tipo diferente), ou seja, usar um
+`data.frame` para armazená-los não é recomendado. Existem três casos
+principais:
+
+  * Quando os dados são uma amostra aleatória de uma única variável, por
+    exemplo. Nesse caso, os dados devem ser armazenados em um vetor. Ele
+    deve ser um vetor nomeado no caso das observações terem rótulo, como
+    o nome da cidade que corresponde ao valor (veja o dado `precip`).
+  * Quando os dados são uma matriz, ou seja, todos os valores
+    correspondem ao mesmo tipo de valor. É o caso, por exemplo, de uma
+    matriz de distâncias entre cidades. Nesse caso, os dados devem ser
+    armazenados como matriz (`matrix`). Pode-se atribuir nome para as
+    linhas e colunas (`rownames` e `colnames`) para identificar os
+    registros.
+  * Quando os dados são uma amostra aleatória não independente, uma
+    séria temporal. Neste caso, no R, há uma classe de objetos `ts`
+    (_Time-Series_) que armazena os valores da amostra junto com a
+    informação da frequência em que foi observada.
+
+## Que tipo de valor usar para as variáveis? ##
+
+É fundamental que os objetos que armazenem as variáveis declarem o tipo
+correto de valor. São 5 os tipos principais:
+
+  * `numeric`: é o tipo de valor para variáveis contínuas. Normalmente
+    essas variáveis tem unidade de medida e números decimais (e.g. 1.85
+    m, 78.5 kg).
+  * `integer`: é o tipo de valor para variáveis discretas (números
+    inteiros). Variáveis de contagem são desse tipo. São também as
+    variáveis que identificam a repetição ou amostra, normalmente
+    sequências que começam em 1. Quando variáveis contínuas tiverem
+    representação que não tenha casas decimais, elas dever ser
+    declaradas como `integer` para salvar espaço em disco e tornar as
+    contas mais rápidas.
+  * `character`: é o tipo de valor para identificar indivíduos, por
+    exemplo, os nomes das cidades, dos bairros, dos pacientes, etc. Note
+    que esses nomes dificilmente se repetem no conjunto de dados são
+    únicos de um indivíduo e não de uma classe/grupo.
+  * `factor`: é tipo de valor para variáveis categóricas. São rótulos
+    que classificam um conjunto de indivíduos/observações com uma
+    variável qualitativa comum. Como exemplo, tem-se os blocos de um
+    experimento em delineamento de blocos casualizados, as observações
+    do mesmo bairro, os indivíduos do mesmo sexo, as parcelas do mesmo
+    local, cultivar, genótipo, variedade, população, etc.
+      * Os fatores devem ter o rótulo mais descritivo possível, ou seja,
+        se os níveis são Kennebec, Huinkul e Buena VIsta (variedades de
+        batatinha) não codifique como 1, 2 e 3. Também não abrevie
+        porque na forma abreviada, a correspondência não é
+        imediata. Quandos os nomes completos são usados, eles aparecem
+        nos gráficos e nas saídas.
+      * Variáveis como sexo (Masculino, Feminino) podem ser
+        abreviadas por M e F, sem prejuízo ao entendimento, pois a
+        correspondência é imediata (é fácil adivinhar que M e F
+        representa masculino e feminino). Da mesma forma, os níveis
+        resistente e suscetível poder ser abreviados para R e S, e os
+        Estados brasileiros podem ser representados pelas siglas.
+      * Nos casos em que os fatores são representados por número
+        inteiros mas são categóricos (como é caso dos blocos do
+        experimento), deve-se usar `factor` ao invés de `integer` para a
+        variável, mesmo que os rótulos continuem a ser os números
+        inteiros. Isso evita erros na interpretação e análise dos
+        dados. Uma opção para os blocos, por exemplo, é usar números
+        romanos, como I, II e III, para representar os diferentes
+        blocos. Para fatores como variedade, uma alternativas é usar
+        letras maiúsculas, como A, B e C, ao invés dos números.
+      * Deve ser feita distinção entre fatores nominais (`factor`) e
+        ordinais (`ordered`).
+  * `logical`: são para variáveis que assumem dois valores (`TRUE`,
+    `FALSE`). Também podem ser representados pelos valores inteiros 1
+    e 0.
+
+Abaixo tem-se o código R para fazer conversão de tipo de valor.
+
+```r
+x <- 1:5
+class(x)
+
+z <- factor(x)
+class(x)
+
+x <- c(1, 2, 3)
+y <- c(1L, 2L, 3L)
+w <- 1:3
+z <- as.integer(x)
+c(class(x), class(y), class(w), class(z))
+
+x <- gl(4, 2)
+class(x)
+
+levels(x) <- LETTERS[1:nlevels(x)]
+str(x)
+```
 
 ## O que colocar na documentação? ##
 
 Os datasets devem ter uma documentação precisa. Existem vários campos da
 documentação que podem ser usados, no entanto, somente 7 serão exigidos.
 
-Abaixo tem-se a documentação do *data.frame* `RamalhoTb4.7`. Embora os
-campos sejam praticamente autoexplicativos, segue breve explicação.
+Uma lista completa com a maioria dos campos está documentada em
+<https://cran.r-project.org/web/packages/roxygen2/roxygen2.pdf>.
+
+Para ilustrar o uso dos campos principais, abaixo tem-se a documentação
+do *data.frame* `RamalhoTb4.7`. Embora os campos sejam autoexplicativos
+por causa do nome, segue breve explicação.
 
   * `@name`: o nome do dataset.
-  * `@title`: título que representa o dataset.
-  * `@description`: descrição do conjunto de dados. Pode conter mais de
-    um parágrafo.
+  * `@title`: título que representa o dataset. Deve estar captalizado,
+    ou seja iniciais maiúsculas, exceto para artigos e preposições.
+  * `@description`: descrição do conjunto de dados, como delineamento,
+    forma de arquisição dos dados, objetivo do estudo,
+    pessoas/organizações envolvidas, hipóteses, etc. Pode conter mais
+    de um parágrafo.
   * `@format `: forma e conteúdo do dataset. Informa as dimensões e cada
     uma das variáveis (nome, descrição, unidade de medida, tipo de
     valor).
@@ -315,12 +509,10 @@ campos sejam praticamente autoexplicativos, segue breve explicação.
 
 ```
 #' @name RamalhoTb4.7
-#' @title Produção de arrozeiro em função de cultivares
-#'
+#' @title Produção de Cultivares de Arroz
 #' @description Produção em função de cultivares de arroz em um
-#'     experimento instalado em delineamento de blocos casualidados.
-#'
-#' @format Um data.frame com 30 linhas e 3 colunas.
+#'     experimento instalado em delineamento de blocos casualizados.
+#' @format Um \code{data.frame} com 30 observações e 3 variáveis, em que
 #'
 #' \describe{
 #'
@@ -332,50 +524,94 @@ campos sejam praticamente autoexplicativos, segue breve explicação.
 #'     experimento.}
 #'
 #' \item{\code{producao}}{Produção de arroz medida em cada parcela
-#' (kg/ha).}
+#'     (kg ha\eqn{^{-1}}).}
 #'
 #' }
-#'
 #' @keywords DBC
-#'
-#' @source Ramalho, M. A. P., Ferreira, D. F., & Oliveira,
+#' @source Ramalho, M. A. P., Ferreira, D. F., Oliveira,
 #'     A. C. de. (2005). Experimentação em genética e melhoramento de
-#'     plantas (2nd ed., p. 322). Editora UFLA. (tabela 7, página 62)
-#'
+#'     plantas (2nd ed., p. 322). Lavras, MG: UFLA. (Tabela 7, pág. 62)
 #' @examples
 #'
 #' library(lattice)
+#'
 #' data(RamalhoTb4.7)
+#' str(RamalhoTb4.7)
 #'
 #' xyplot(producao ~ cultivar, groups = bloco, data = RamalhoTb4.7,
-#'        ylab="Produção (kg/ha)", xlab="Cultivar")
+#'        ylab = expression("Produção"~(kg~ha^{-1})),
+#'        xlab = "Cultivares de arroz")
 #'
 NULL
 ```
 
+Nesse exemplo de documentação, atente para o seguinte:
+
+  * O título está captalizado e não termina com pontuação;
+  * O uso de `\code{}` para as descrição das variáveis que exibe esses
+    textos em fonte monoespaço. Cada `\item` descreve uma variável e a
+    ordem deles deve ser a mesma ordem das colunas no `data.frame`. A
+    decrição termina com ponto final.
+  * A referência bibliográfica no formato APA sem o `&` separando os
+    últimos dois autores. A referência contém cidade, estado e
+    editora. No final tem-se a referência e página sobre o dataset.
+  * Na sessão exemplos, usa-se `data()` e `str()` para o dataset. No
+    código da sessão exemplo, os gráficos ou tabelas devem priorizar
+    visualizações mais próximas das hipóteses ou interesse do
+    pesquisador. Sendo assim, a produção está em função das cultivar e
+    não dos blocos porque o interesse é estudar a cultivar, já o bloco
+    está presente para haver controle local.
+  * A representação das unidades de medida está em notação de potência
+    na documentação (`\eqn{}`) e no código da seção exemplos
+    (`expression()`).
+  * A indentação negativa de 4 espaços e largura de 72 digitos para fazer
+    quebra de linhas.
+
+Para gerar a citação bibliográfica no formato APA, padrão considerado no
+pacote, visite <http://www.citationmachine.net/apa/cite-a-book/manual> e
+preencha as informações. Use o resultado gerado para citar a obra.
+
+Em certas situações, o campo `@seealso` (veja também) pode ser usado. É
+o caso de dois arquivos de dados serem "irmãos", ou seja, são duas
+tabelas de experientos de mesma estrutura feitos em anos consecutivos,
+em locais diferentes, ou alguma outra condição de contorno diferente.
+
+Recentemente foi habilitado o uso de figuras nas páginas de documentação
+do R. Visite
+<https://cran.r-project.org/doc/manuals/R-exts.html#Figures> para
+detalhes.
+
 Por razão ainda desconhecida, títulos com acentos são substituídos por
 `NA` no manual em PDF. Na documentação em HTML, no entanto, e produzida
 sem erros.
 
-Perceba a indatação de 4 espaços e que largura de 72 digitos usada para
-escrever a documentação.
+## Como dar nomes as vinhetas? ##
 
-Para gerar a citação bibliográfica no formato APA, padrão considerado no
-pacote, visite <http://www.citationmachine.net/apa/cite-a-book/manual> e
-preencha as informações. Use o resultado gerado para vitar a obra.
+TODO
+
+## Como habilitar no `DESCRIPTION` ##
+
+No caso de usar algum pacote que não seja da lista de pacotes básicos do
+R (aqueles que estão disponíveis na instalação mínima padrão), é
+necessário acrescentar o pacote a lista de pacotes na seção `Imports` ou
+`Suggests` do arquivo `DESCRIPTION`. Você pode editar o arquivo mas
+esteja atento para indentação e uso das vírgulas nesses campos. É
+aconselhado usar a função `devtools::use_package()`.
 
-<!--
-<http://ase-research.org/R/>
-<http://r-pkgs.had.co.nz/man.html#man-data>
--->
+```r
+use_package(package = "lattice", type = "Imports")
+use_package(package = "plyr", type = "Suggests")
+```
 
 ## Como criar um *issue*? ##
 
 De uma maneira simples, um *issue* é uma tarefa. Quando você cria um
 *issue*, você está documentando algo que precisa ser feito. Essas
-tarefas podem ser relacionadas à criação ou correção no seu pacote.
+tarefas podem ser relacionadas à adições (criar novos arquivos, criar
+conteúdo em arquivos) ou correção (ortográficas, em código) no seu
+pacote.
 
-Na página do repositório existe uma entrada chama
+Na página do repositório existe uma entrada chamada
 [*Issues*](https://gitlab.c3sl.ufpr.br/pet-estatistica/labesData/issues)
 no menu esquerdo. Ao entrar nessa página, existe um botão de create
 [new issue](https://gitlab.c3sl.ufpr.br/pet-estatistica/iguir2/issues/new?).
@@ -385,19 +621,25 @@ Na página de criar um *issue*, você deve preencher os seguintes campos:
   * Title: com um título que representa o seu *issue*.
   * Description: com uma descrição detalhada do que deve ser feito no
     *issue*.
-  * Assignee: com quem é o responsável pelo desenvolvimento do issue*.
+  * Assignee: com quem é o responsável pelo desenvolvimento do *issue*.
   * Milestone: com a marca de milha a que o *issue* pertence, se alguma.
   * Labels: com as palavras chaves apropriadas para o *issue*, se
     alguma.
 
 No projeto **labesData** são adotadas como _Milestones_, as obras
 elencadas para transcrição dos dados ao pacote e os _Labels_ são as
-disciplinas Estatísticas que a obra coompreende. Por exemplo, ao criar
-um _issue_ que propõe a adição de três conjuntos de dados do capítulo 3
-do livro Estatística Multivariada de Ferreira (2011) deve-se selecionar
-a _milestone_ `Ferreira` e o _label_ `Análise Multivariada`.
-
-Feito isso, clique em *Submit issue*.
+disciplinas Estatísticas que a obra coompreende. Visite ambos:
+[milestones](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones)
+e
+[labels](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/labels).
+Por exemplo, ao criar um  *issue* que propõe a adição de três conjuntos
+de dados do capítulo 3 do livro Estatística Multivariada de Ferreira
+(2011) deve-se selecionar a _milestone_ `Ferreira` e o _label_ `Análise
+Multivariada`.
+
+Feito isso, clique em *Submit issue*. Seu *issue* vai ter um número
+associado e todos os membros do projeto poderão consultar o seu *issue*
+para saber detalhes sobre o que irá ser feito.
 
 ## Quanto de trabalho representa um *issue*? ##
 
@@ -413,18 +655,19 @@ verificações de *build*. No primeiro caso, por outro lado, se o trabalho
 é texto, por exemplo, mesmo que este esteja incompleto a verificação de
 *build* será verde.
 
-## Como fechar ou editar um issue ##
+## Como fechar ou editar um *issue* ##
 
 Para editar, basta acessar o menu
 [*Issues*](https://gitlab.c3sl.ufpr.br/pet-estatistica/labesData/issues)
 e abrir o *issue* desejado. A edição permite editar praticamente tudo,
 embora seja desaconselhado modificar o título e descrição do
 mesmo. Deve-se dedicar na hora de atribuir título e descriação para que
-sejam apropriados e sem necessidade de mudar.
+sejam apropriados e sem necessidade de mudar no futuro. Essa é a
+filosofia do faça certo de primeira (*do it right the first time*).
 
 Na página de um *issue* é possível fazer uma discussão sobre ele, bem
-como atribuir a outro colaborador. Quandor o issue for concluído, ou
-seja quando o ramo dedicado as tarefas descritas neste _issue_ for
+como atribuir a outro colaborador. Quandor o *issue* for concluído, ou
+seja quando o ramo dedicado as tarefas descritas neste *issue* for
 mesclado ao `devel`, deve-se fechá-lo.
 
 ## Como fazer mensagens de *commit*? ##
@@ -433,7 +676,7 @@ Mensagens de *commit* são de duas formas: simples e composta (mono ou
 multi linhas). As mensagens simples são aquelas que ocupam uma linha
 apenas, normalmente com uma única sentença. Elas descrevem modificações
 cuja descrição cabe em uma linha de 72 caracteres. Você pode escrever na
-própria linha de instrução do commit, como a seguir.
+própria linha de instrução do *commit*, como a seguir.
 
 ```
 git commit -m "Minha mensagem de uma linha aqui."
@@ -443,8 +686,8 @@ As mensagens compostas, por outro, servem para documentar várias
 modificações. Então não é possível usar a opção `-m`. Apenas faça `git
 commit` seguido de ENTER que um editor de terminal vai abrir para que
 você escreva a mensagem de *commit*. Normalmente o editor é o vi ou
-nano, mas outros podem ser habilitados. Abaixo um exemplo de mensagem
-composta.
+nano, mas outros podem ser habilitados editando o arquivo `.gitcongif`
+que fica na sua *home*. Abaixo um exemplo de mensagem composta.
 
 ```
 Inclui dataset da página 103
@@ -456,31 +699,35 @@ Inclui dataset da página 103
 ```
 
 As mensagens de *commit* devem ter verbos conjugados no presente do
-indicativo (faz, completa, adiciona, remove, edita, conserta,
-produz, gera, corrige, documenta, escreve, move, transforma, modifica).
+indicativo (faz, completa, adiciona, remove, edita, conserta, produz,
+gera, corrige, documenta, escreve, move, transforma, modifica). A
+mensagem de commit, simples ou composta, não deve ultrapassar 72
+caracteres de comprimento por linha.
 
 ## Como criar um *merge request*? ##
 
-Criar um *merge request* (requisição de junção), acesse o menu
+Criar um *merge request* (requisição de junção/mescla), acesse o menu
 [*Merge resquest*](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/merge_requests)
 e preencha de forma semelhante ao que se faz com o *issue*.
 
 Note que a descrição do *issue* representa o será feito e do *merge
-request* o que foi feito.
+request* o que foi de fato feito.
 
 ## Quais as exigências para aceitar um *MR*? ##
 
-Para que um *merge request* seja aceito, 3 condições precisam ser
-satisfeitas:
+Para que um *merge request* seja aceito, 3 condições principais precisam
+ser atendidas:
 
   1. O trabalho deve estar concluído. Isso significa de o que previsto
      precisa ser cumprido. Em caso de não conclusão, uma justificativa
-     deve ser dada e aceita. 
-  2. O *branch* tem que ter *build sucess*. A vantagem, dentre muitas,
-     da integração contínua, é sabermos se um ramo tem problemas de
-     código. Se um *branch* não passa nas verificações do *build*,
-     quando deveria passar, então algo está errado e precisa ser
-     consertado.
+     deve ser dada e aceita.
+  2. O *branch* tem que ter *build sucess* (estar verde). A vantagem,
+     dentre muitas, da integração contínua, é permitir saber se um ramo
+     tem problemas de código. Se um *branch* não passa nas verificações
+     do *build* (está vermelho), quando deveria passar, então algo está
+     errado e precisa ser consertado. Se não foi possível detectar a
+     causa de falha no *build* comunique que inspeções já foram feitas
+     na tentativa de solucionar o problema (dê a trilha percorrida).
   3. O trabalho deve estar em conformidade com o Guia de Estilo de
      Código. Ainda que o *branch* esteja verde - com *build status*
      positivo - o *merger* (pessoa responsável pelo *merge*) deve
@@ -488,27 +735,37 @@ satisfeitas:
      Guia de Estilo de Código. Não havendo conformidade, ele vai indicar
      as correções a serem feitas.
 
+Além dos pontos acima, um MR pode não ser aceito por precisar de
+revisões/correções não relacionadas com os pontos acima. Por exemplo,
+faltar declarar fatores como `factor`, incluir a unidade de medida das
+variáveis, modificar o código da seção exemplos.
+
 ## Existe um *checklist* para incluir um *dataset*? ##
 
-Na lista que segue abaixo, dados representa o nome do dataset e o
+Na lista que segue abaixo, `dados` representa o nome do dataset e o
 diretório raíz é o `/labestData`.
 
   1. Criar o `dados.txt`. Criar o arquivo texto com os dados no
-     diretório `./data-raw`. Usar TAB com separador de campo e ponto
-     como separador decimal.
+     diretório `./data-raw`. Usar TAB com separador de campo, ponto
+     como separador decimal, sem nomes nas linhas e sem aspas.
   2. Criar o `dados.rda`. Carregar o `dados.txt` e criar a imagem do
      objeto (`*.rda`) no diretório `./data`. A forma mais simples é usar
      a função `devtools::use_data(dados)`.
-  3. Fazer a documentação dos dados. Criar o arquivo `dados.R` no
-     diretório `./R/`.
+  3. Escrever a documentação dos dados. Criar o arquivo `dados.R` no
+     diretório `./R/`. Lembre-se dos campos obrigatórios e esteja atento
+     das recomendações dadas na seção
+     [sobre documentação](#o-que-colocar-na-documentao).
   4. Gerar o arquivo `dados.Rd`. Com o comando `devtools::document()`
      gerar os arquivos de documentação que ficam no diretório
-     `./man`. Use `devtools::check_man()` para verificar a documentação.
+     `./man`. Use `devtools::check_man()` para verificar se a
+     documentação foi escrita corretamente. Erros de grafia ou
+     preenchimento nos campos e ambientes são identificados aqui.
   5. Por fim, execute `devtools::check()` e `devtools::build()`. Observe
      se ocorrem notificações de `ERROR`, `WARNING` ou `NOTE`. Faça
      correções para removê-las.
 
-No final, você deve ter a essa estrutura de diretório abaixo
+No final, considerando apenas os arquivos do `dados`, você deve ter a
+essa estrutura de diretório abaixo
 
 ```
 labestData/
diff --git a/DESCRIPTION b/DESCRIPTION
index bf26121dd6c181563e4e915478dd964a78327e8b..64f998a1b18663c63686a5f9788a775688d10b35 100644
--- a/DESCRIPTION
+++ b/DESCRIPTION
@@ -1,6 +1,7 @@
 Package: labestData
 Title: Conjuntos de Dados para Ensino de Estatística
 Version: 0.0-1
+Date: 2016-04-05
 Authors@R: as.person(c(
     "PET Estatística UFPR <pet.estatistica.ufpr@gmail.com> [cre]",
     "Altamiro Antonio Basiewics <alfbasiewics@bol.com.br> [ctb]",
@@ -28,17 +29,20 @@ URL: http://gitlab.c3sl.ufpr.br/pet-estatistica/labestData
 BugReports: http://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/issues
 LazyData: true
 Encoding: UTF-8
-Depends: 
+Depends:
     R (>= 3.2.3)
-Suggests: 
+Suggests:
     lattice,
     latticeExtra,
     reshape,
     ggplot2,
     car,
-	knitr,
-	rmarkdown,
-	shiny,
-    reshape2
+    knitr,
+    rmarkdown,
+    shiny,
+    reshape2,
+    MASS,
+    qcc,
+    multicomp
 VignetteBuilder: knitr
 RoxygenNote: 5.0.1
diff --git a/README.md b/README.md
index 410bd3d8eeb6d221c5543bd0e47d5e1e63e277e2..a922c37c7d72d7f30c3088b1edfb15874372503b 100644
--- a/README.md
+++ b/README.md
@@ -2,6 +2,12 @@
 
 **PET Estatística UFPR** - <pet.estatistica.ufpr@gmail.com>
 
+[![Build Status](https://travis-ci.org/pet-estatistica/labestData.svg?branch=master)](https://travis-ci.org/pet-estatistica/labestData)
+Build status for the stable version (`master` branch)
+
+[![Build Status](https://travis-ci.org/pet-estatistica/labestData.svg?branch=devel)](https://travis-ci.org/pet-estatistica/labestData)
+Build status for the development version (`devel` branch)
+
 > “Without data, you're just another person with an opinion.”
 >
 >> -- W. Edwards Deming
@@ -37,7 +43,7 @@ Estatística Multivariada.
 
 <!-- Inserir links das milestones que representam os livros -->
 1. Banzatto, D. A., Kronka, S. D. (2013). **Experimentação Agrícola**
-   (4th ed.). Jaboticabal, SP: Funep.
+   (4th ed.). Jaboticabal, SP: Funep.  
    [_Milestone_ Banzatto](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/1)
    <!-- [*Walmes Zeviani*](https://gitlab.c3sl.ufpr.br/walmes) -->
 
@@ -71,7 +77,7 @@ Estatística Multivariada.
 
 8. Ferreira, D. F. (2011). **Estatística Multivariada** (2nd
    ed.). Lavras, MG: Editora UFLA.  
-   [_Milestone_ Mingoti](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/8)
+   [_Milestone_ Ferreira](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/8)
    <!-- [*Eduardo Junior*](https://gitlab.c3sl.ufpr.br/eerj12) -->
 
 9. Manly, B. J. F. (2005). **Métodos Estatísticos Multivariados- uma
@@ -82,13 +88,13 @@ Estatística Multivariada.
 10. Storck, L., Garcia, B. C., Lopes, S. J., Estefanel,
     V. (2011). **Experimentação Vegetal** (3th ed.). Santa Maria, RS:
     Editora UFSM.  
-   [_Milestone_ Manly](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/10)
+   [_Milestone_ Storck](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/10)
    <!-- [*Mônica Ludmilla*](https://gitlab.c3sl.ufpr.br/mlho15) -->
 
 11. Charnet, R., de Luna Freire, C.A., Charnet, E.M.R., Bonvino,
    H. (2008). **Análise de modelos de regressão linear com aplicações**
    (2nd ed.). Campinas, SP: Editora Unicamp  
-   [_Milestone_ Pimentel-Gomes](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/11)
+   [_Milestone_ Charnet](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/11)
     <!-- [*Daniel Ikenaga*](https://gitlab.c3sl.ufpr.br/di12) -->
 
 12. Demétrio, C. G. B., & Zocchi, S. S. (2011). **Modelos de
@@ -96,6 +102,33 @@ Estatística Multivariada.
    [_Milestone_ Demetrio](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/12)
    <!-- [*Alcides Neto*](https://gitlab.c3sl.ufpr.br/acn13) -->
 
+13. Ramos, E. M. L. S., & Almeida, S. S, & Araújo,
+   A. R. (2013). **Controle Estatístico da Qualidade** (1th ed.). Porto
+   Alegre, RS: Bookman.  
+   [_Milestone_ Ramos](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/13)
+   <!-- [*Ângela Legey*](https://gitlab.c3sl.ufpr.br/alcl12) -->
+
+14. Costa, A. F. B., Epprecht, E. K., Carpinetti, L. (2010).  **Controle
+   Estatístico de Qualidade** (2nd ed.). São Paulo - SP: Editora
+   Atlas.  
+   [_Milestone_ Epprecht](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/14)
+   <!-- [*Paula Alessandra*](https://gitlab.c3sl.ufpr.br/pazd11) -->
+
+15. Barbin, D. (2013). **Planejamento e Análise Estatística de
+   Experimentos Agronômicos** (2nd ed.). Londrina, PR: Mecenas.  
+   [_Milestone_ Barbin](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/15)
+   <!-- [*Walmes Zeviani*](https://gitlab.c3sl.ufpr.br/walmes) -->
+
+16. Paula, G. A. (2004). **Modelos de regressão: com apoio
+   computacional**. São Paulo, SP: IME-USP.  
+   [_Milestone_ Paula](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/16)
+   <!-- [*Eduardo Junior*](https://gitlab.c3sl.ufpr.br/eerj12) -->
+
+17. Vieira, S.(1999). **Estatística experimental** (2th ed.). São Paulo, SP: Atlas.  
+   [_Milestone_ Vieira](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/17)
+   <!-- [*Ângela Legey*](https://gitlab.c3sl.ufpr.br/alcl12) e -->
+   <!-- [*Alcides Neto*](https://gitlab.c3sl.ufpr.br/acn13) -->
+
 Ao término desta primeira fase pretende-se ter todos os conjuntos de
 dados relevantes destas obras disponíveis para usuários do pacote. Ainda
 *vignettes* (vinhetas), exemplificando a análise de dados (em códigos R)
@@ -112,14 +145,14 @@ professores.
 |----------------------------------|------------|---------|---------|
 | Alcides Conte Neto               | Voluntário | S       | -       |
 | Altamiro Antonio Basiewics       | Petiano    | S       | -       |
-| Angela Luiza Cunha Legey         | Petiana    | S       | -       |
+| Ângela Luiza Cunha Legey         | Petiana    | S       | -       |
 | Bruna Davies Wundervald          | Petiana    | S       | -       |
 | Bruno Geronymo                   | Petiano    | S       | -       |
 | Daniel Ikenaga                   | Petiano    | S       | -       |
 | Eduardo Elias Ribeiro Junior     | Petiano    | S       | -       |
 | Gabriel Sartori Klostermann      | Petiano    | S       | -       |
 | Jhenifer Caetano Veloso          | Petiana    | S       | -       |
-| Monica Ludmila Hintz De Oliveira | Petiana    | S       | -       |
+| Mônica Ludmila Hintz De Oliveira | Petiana    | S       | -       |
 | Paula Alessandra Zeizer Dimas    | Petiana    | S       | -       |
 | Walmes Marques Zeviani           | Professor  | S       | -       |
 | Cesar Augusto Taconeli           | Professor  | S       | -       |
@@ -149,13 +182,13 @@ fontes:
      site com materiais suplementares. Essa será a maior fonte de dados
      para o pacote labestData.
   2. Internet. A internet está repleta de dados. Existem dados prontos
-     em formas de tabela (páginas pessoais, orgãos públicos, instiuições
+     em formas de tabela (páginas pessoais, órgãos públicos, instituições
      de pesquisa, resultados de enquetes, etc) e também dados não
      tabulados/organizados que podem ser capturados (com *web scrap*,
      por exemplo) e processados.
   3. Arquivos pessoais. Alunos, professores, pesquisadores também podem
      disponibilizar os dados de suas pesquisas para inclusão no pacote.
-  4. Simulação. Embora sejam artificiais, dados proveninentes de
+  4. Simulação. Embora sejam artificiais, dados provenientes de
      simulação podem ser considerados pois, muitas vezes, são
      deliberadamente feitos com uma particular característica relevante
      para um problema. No pacote labestData essa será a menor fonte de
@@ -171,7 +204,7 @@ proprietários dos dados, pessoas ou instituições.
 
 Por razões de conveniência, a primeira etapa do pacote irá priorizar
 dados correspondentes às disciplinas de Análise de Regressão Linear
-(CE071), Planjamento de Experimentos I (CE213) e Métodos Estatísticos
+(CE071), Planejamento de Experimentos I (CE213) e Métodos Estatísticos
 Multivariados (CE090). No Curso de Estatística da UFPR, essas
 disciplinas são ofertadas no primeiro semestre. Na segunda etapa, os
 dados irão priorizar as disciplinas de Modelos Lineares Generalizados
@@ -181,7 +214,7 @@ semestre para o Curso de Estatística da UFPR.
 
 Embora sejam esses os contextos de prioridade, dados de outras áreas são
 igualmente bem vindos, como dados espaciais, séries temporais, de
-análise de sobreviência, de questionário, etc.
+análise de sobrevivência, de questionário, etc.
 
 Os dados reais devem possuir uma boa descrição das variáveis (nome,
 unidade de medida, instrumento de medida usado, definição da unidade
diff --git a/STYLEGUIDE.Rmd b/STYLEGUIDE.md
similarity index 67%
rename from STYLEGUIDE.Rmd
rename to STYLEGUIDE.md
index 5756294fdbf2cf968a152e7b810c6df66765a757..de7a52315d6edd6927fc1da8c5c38333c11a1e0f 100644
--- a/STYLEGUIDE.Rmd
+++ b/STYLEGUIDE.md
@@ -1,6 +1,9 @@
-% Guia de Estilo R - LEG/PET UFPR
-% Walmes Zeviani, Fernando Mayer & Eduardo Jr.
-% 01/2016
+Guia de Estilo de Escrita de Código R
+=====================================
+
+Walmes Zeviani - LEG/DEST/UFPR\
+Fernando Mayer - LEG/DEST/UFPR\
+Eduardo Jr - PET Estatística/UFPR
 
 ****
 
@@ -10,20 +13,64 @@
 
 >> -- Paul E. Johnson, R Style. An Rchaeological Commentary.
 
-<!--
-<https://cran.r-project.org/web/packages/rockchalk/vignettes/Rstyle.pdf>
-<https://google.github.io/styleguide/Rguide.xml>
-<http://web.stanford.edu/class/cs109l/unrestricted/resources/google-style.html>
-<http://adv-r.had.co.nz/Style.html>
-<http://r-research-tool.schwilk.org/handouts/style-guide.html>
-<https://github.com/rdatsci/PackagesInfo/wiki/R-Style-Guide>
-<http://static.googleusercontent.com/media/research.google.com/pt-BR//pubs/archive/42577.pdf>
-<http://ess.r-project.org/>
--->
+**Sumário**
+
+  - [Nomes de arquivos](#nomes-de-arquivos)
+  - [Nomes de objetos](#nomes-de-objetos)
+      - [Contadores](#contadores)
+      - [Matrizes](#matrizes)
+  - [Atribuição](#atribuio)
+  - [Indentação](#indentao)
+  - [Operadores](#operadores)
+  - [Alinhamento vertical de referência (nos operadores)](#alinhamento-vertical-de-referncia-nos-operadores)
+  - [Vírgulas](#vrgulas)
+  - [Lagura de texto](#lagura-de-texto)
+  - [Quebras de linha](#quebras-de-linha)
+  - [Comentários](#comentrios)
+  - [Divisões de código](#divises-de-cdigo)
+  - [Linhas em branco](#linhas-em-branco)
+  - [Aspas](#aspas)
+  - [Chaves](#chaves)
+  - [Colchetes](#colchetes)
+  - [Parênteses](#parnteses)
+  - [Ponto e vírgula](#ponto-e-vrgula)
+  - [Documentação embutida de funções](#documentao-embutida-de-funes)
+  - [Carregando pacotes](#carregando-pacotes)
+
+Um Guia de Estilo de Código é um conjunto de recomendações (ou regras)
+para padronizar a forma de escrever código.  Códigos que são escritos
+seguindo um estilo padrão são mais fáceis de manter, modificar e
+garantir que estão corretamente escritos e funcionais, principalmente
+quando muitos programadores estão envolvidos.
+
+Quase todas as linguagem de programação permitem que os usuários adotem
+diferentes padrões de escrita de código.  Algumas não diferenciam
+maiúsculas e outras não exigem indentação, por exemplo. Em função de
+simplicidade, comodismo ou inércia na hora de escrever ou por causa de
+características da linguagem ou do editor usado, os usuários quase
+sempre tem um padrão particular para escrita de código.
+
+Esse é um Guia de Estilo Código estabele as convenções a serem seguidas
+para escrita de código R. Esse documento é baseado na consulta à varias
+fontes e deliberações próprias em alguns casos. A lista das principais
+fontes na qual esse Guia é baseado está abaixo.
+
+  * Guia de Estilo por [Hadley Wickham]:
+    <http://adv-r.had.co.nz/Style.html>.
+  * Guia de Estilo do Google:
+    <https://google.github.io/styleguide/Rguide.xml>.
+  * Guia de Estilo por
+    [Dylan Schwilk](http://www.depts.ttu.edu/biology/people/faculty/schwilk/)
+    <http://r-research-tool.schwilk.org/handouts/style-guide.html>.
+  * Guia de Estilo do R Data Science:
+    <https://github.com/rdatsci/PackagesInfo/wiki/R-Style-Guide>.
+  * Nota de Paul Johnson estilo de escrita de código:
+    <https://cran.r-project.org/web/packages/rockchalk/vignettes/Rstyle.pdf>.
 
+****
 ## Nomes de arquivos ##
 
-Nomes de arquivos R dever ter o sulfixo maiúsculo.
+Nomes de arquivos R devem ter o sulfixo maiúsculo.
 
 ```
 # Bom.
@@ -35,10 +82,10 @@ script.r
 
 No entanto, o nome do arquivo não pode ser vago como `script` -- que é
 algo óbvio. Use nomes com significado. Se for preciso, use um nome
-composto, mas não use espaços nos nomes (nem para diretórios). Dê
-preferência para o *undescore* como separador, já que ponto separa a
-extensão do nome e traço é separador de palavras compostas
-(guarda-chuva, super-homem, ex-aluno).
+composto, mas não use espaços nos nomes (nem para diretórios). Isso
+evita um tanto de problemas de `path`. Dê preferência para o *undescore*
+como separador, já que ponto separa a extensão do nome e traço é
+separador de palavras compostas (guarda-chuva, super-homem, ex-aluno).
 
 ```
 # Bom.
@@ -55,7 +102,7 @@ maiúsculo também, além de nomes não vagos ou óbvios.
 
 Se em um conjunto de arquivos houver relação sequêncial entre eles,
 destaque isso no nome. Por exemplo, componha nomes com números
-antecedidos de mesmo prefixo.
+precedidos do mesmo nome.
 
 ```
 # Bom.
@@ -66,38 +113,40 @@ cap1_introducao.Rmd, cap2_exploratoria.Rmd, ..., cap5_conclusoes.Rmd
 A vantagem de colocar um prefixo numerado é que os arquivos são exibidos
 em sequência no seu navegador de arquivos quando a ordenação for
 alfabética. Mas lembre-se que a ordenação é léxica e por isso `cap23*`
-aparece antes de `cap4*`. Evite usando `cap04`.
+aparece antes de `cap4*`. Evite usando zeros à esqueda, `cap04`.
 
 ## Nomes de objetos ##
 
 Nomes de objetos devem ter um bom compromisso entre significado e
-praticidade. Ou seja, não deve ser curto ao ponto de perder significado
-nem longo ao ponto de demorar para escrever. Quanto maior um nome, mais
-erramos ao escrevê-lo. Principalmente quando contém acentos, certo?
-Portanto, evite nomes que levem acentos (âãàáçêéíôõóú).
+praticidade (ou digitabilidade). Ou seja, não deve ser curto ao ponto de
+perder significado nem longo ao ponto de demorar para escrever. Quanto
+maior um nome, mais erramos ao escrevê-lo. Principalmente quando contém
+acentos, certo?  Portanto, evite nomes que levem acentos (âãàáçêéíôõóú).
 
 Dependendo da classe e da quantidade de objetos na sua sessão
 ou pacote, você pode ser mais ou menos verboso (usar nomes maiores ou
-menores) na hora de defini-los.
+menores) na hora de defini-los para devidamente distingui-los.
 
 Existem 3 estilos predominantes para escrita de nomes de objetos:
 
   * *dot.case*: é o estilo que usa o separador como ponto. Foi o
-  primeiro a usado no R e inclusive incentivado. Tem-se várias funções
-  com esse padrão no R (todas as `read.`, `as.`, `is.`). A mais notáveis
-  são sa funções método nas quais o ponto separa o nome da a função
-  genérica da classe o objeto que ela recebe. Por exemplo, `anova.lm` é
-  a função que retorna o quadro de ANOVA para objetos da classe
-  `lm`. Nesse caso o ponto tem função além da estética e não pode ser
-  substituído por nada.
+    primeiro a usado no R e inclusive incentivado por algum tempo. Uma
+    prova disse são as várias funções com esse padrão no R (todas as
+    `read.`, `as.`, `is.`, por exemplo). A mais notáveis são sa funções
+    método nas quais o ponto separa o nome da a função genérica da
+    classe o objeto que ela recebe. Por exemplo, `anova.lm` é a função
+    que retorna o quadro de ANOVA para objetos da classe `lm`. Nesse
+    caso o ponto tem função além da estética e não pode ser substituído
+    por nada.
   * *snake_case*: é o estilo que usa o *underscore* como separador. O
-  pacote [devtools], do Hadley Wickham, usa esse padrão. No pacote
-  [mcglm] esse estilo também foi adotado integralmente. Muitos
-  consideram um custo digitar o *underscore* ao passo que outros
-  argumentam que facilita a leitura.
+    pacote [devtools], do [Hadley Wickham], usa esse padrão. No pacote
+    [mcglm] esse estilo também foi adotado integralmente. Muitos
+    consideram um custo digitar o *underscore* (combina teclas) ao passo
+    que outros argumentam que facilita a leitura (pois é um traço
+    rasteiro sem altura).
   * *camelCase*: é o estilo que usa letras maiúsculas para as iniciais
-  das palavras com exceção da primeira delas. O pacote [car], do John
-  Fox, usa esse estilo.
+    das palavras, com exceção da palavra inicial. O pacote [car], do
+    [John Fox], usa esse estilo.
 
 Uma quarto estilo é o *PascalCase* que difere do *camelCase* porque
 todas as iniciais são maiúsculas. A mesma função teria os seguintes
@@ -110,7 +159,7 @@ reserva do ponto é para as funções método, assim, para objetos não
 existe problema.
 
 O importante é que você seja consistente, assuma e mantenha o mesmo
-estilo em todo seu pacote ou scritps. Um exemplo de projeto aberto em
+estilo em todo seu pacote ou *scripts*. Um exemplo de projeto aberto em
 que todos seguem o padrão é no Emacs, onde todos os objetos usam o
 *dot-case*.
 
@@ -128,10 +177,10 @@ interessante também porque é comum o contador do *loop* ser usado para
 selecionar frações dos objetos (elementos, linhas, colunas, etc), dentro
 dos colchetes simples ou duplos, deixando o código mais claro.
 
-```{r, eval=FALSE}
+```r
 x <- 1:10
 for (i in 1:length(x)) {
-    x[i] <- sum(x[1:i])+i
+    x[i] <- sum(x[1:i]) + i
 }
 ```
 
@@ -149,9 +198,9 @@ matrizes e sair do R (*quit*) e as últimas são abreviações de `TRUE` e
 ## Atribuição ##
 
 Faça atribuição de objetos com o sinal de atribuir (`<-`) e não com o
-igual. Deixe espaço cercar o operador.
+de igual. Deixe espaço cercar o operador.
 
-```{r, eval=FALSE}
+```r
 # Bom.
 x <- 1:10
 notas <- data.frame(aluno, freq, nota)
@@ -165,11 +214,11 @@ x=1:10
 notas<-data.frame(aluno, freq, nota)
 ```
 
-O sinal de igual, embora faça atribuição, não deve ser usado para
+O sinal de igual, embora faça atribuição também, não deve ser usado para
 isso. Reserva-se a passar valores para os argumentos de uma função ou
 nomear os elementos de objetos.
 
-```{r, eval=FALSE}
+```r
 # Nomes que levam certos caracteres devem declarados como string.
 notas <- c(Carlos = 95, Lucas = 89, Pedro = 77, "Antônio Augusto" = 60)
 ```
@@ -177,20 +226,21 @@ notas <- c(Carlos = 95, Lucas = 89, Pedro = 77, "Antônio Augusto" = 60)
 ## Indentação ##
 
 A indentação é um dos requisitos fundamentais de estilo de código. É
-praticamente impossível compreender um código se ele não estiver
-devidamente indentado. Todo editor de texto voltado para programação tem
-recursos de indentação.
-
-A indentação do R é com 4 espaços. Não se usa tabulação.  É comum código
-com tabulação de 2 espaços, que é inclusive a opção *default* do
-[RStudio].  Programadores argumentam que a indentação com 2 espaços
-impõe pouca evidência da hierarquia do código, principalmente para
-fontes de texto que sejam finas. Além disso, 4 espaços é equivalente a
-uma tabulação (que não devem ser usadas).  Para mudar o número de
-tabulações do [RStudio], vá em `Tools > Global options > Code > Editing`
-e em `Tab width` use 4. O [Emacs] usa 4 espaços por *default*.
-
-```{r, eval=FALSE}
+perda de tempo tentar compreender um código que não está devidamente
+indentado. Todo editor de texto voltado para programação tem recursos de
+indentação.
+
+A indentação em código R é com 4 espaços. Não se usa tabulação.  É comum
+encontrar código com tabulação de 2 espaços, que é inclusive a opção
+*default* do [RStudio].  Programadores argumentam que a indentação com 2
+espaços impõe pouca evidência da hierarquia do código, principalmente
+para fontes de texto que sejam finas.  Além disso, 4 espaços é
+equivalente a uma tabulação (que não devem se usada).  Para mudar o
+número de tabulações do [RStudio], vá em `Tools > Global options > Code
+> Editing` e em `Tab width` use 4. O [Emacs] usa 4 espaços por
+*default*.
+
+```r
 # Bom.
 for (i in 1:3) {
     if (a > 0) {
@@ -221,14 +271,15 @@ Deixe espaços ao redor dos operadores lógicos e matemáticos.
   * Operadores lógicos: `==`, `!=`, `<`, `<=`, `>`, `>=`, `%in%`, `&`,
     `&&`, `|`, `||`.
   * Operadores matemáticos: `+`, `-`, `*`, `%*%`, `%%`, `%/%`, `%o%`. Os
-    operadores `^` e `/` são considerados excessões e não devem ter
-    espaços. Embora `**` seja um operador equivalente ao `^`, seu uso é
-    evitado.
+    operadores `^` e `/` são considerados exceções e não devem ter
+    espaços. Embora `**` seja um operador equivalente ao `^`, seu uso
+    não é recomendado.
 
-Certas situações fogem a regra. Observe abaixo o emprego do sinal de
-menos e para o operador `~`, usado em fórmulas.
+Certos operadores tem emprego diferenciado dependedo do que
+precede. Observe abaixo o emprego do sinal de menos e para o operador
+`~`, usado em fórmulas.
 
-```{r, eval=FALSE}
+```r
 # Diferença para o menos de negativo e menos de subtração.
 x <- -5 + 2
 x <- 2 - 5
@@ -244,7 +295,7 @@ usados com espaços. O mesmo vale para o operador `$`, usado para
 consultar listas de data frames, e o `@`, usados para consultar listas
 de objetos S4.
 
-```{r, eval=FALSE}
+```r
 # Uma sequência regular.
 12:15
 
@@ -282,7 +333,7 @@ m0$fitted
 Quando alinhamento vertical (*columnate*) de referência em um operador
 der mais clareza ao código, isso pode ser feito.
 
-```{r, eval=FALSE}
+```r
 altura  <- rnorm(100, mean = 1.8, sd = 0.1)
 peso    <- rnorm(100, mean = 70, sd = 5)
 idade   <- sample(20:50, size = 100, replace = TRUE)
@@ -295,15 +346,15 @@ plot(peso ~ altura,
 ```
 
 Esse padrão vai exigir mais trabalho e não são muitos os editores que
-tem o recurso de indentação por referência. O trabalho de indentar
-manualmente e manter isso nas revisões futuras e por colaboradores deve
-ter peso na decisão de usar. O [Emacs] tem o recurso de indentação
-baseado em expressão regular. Para aplicá-lo aos sinais de igual,
-selecione o texto e dê `M-x align-regexp RET = RET`. Você pode, se usar
+tem o recurso de indentação por referência.  O trabalho de indentar
+manualmente e manter isso nas revisões deve ter peso na decisão de
+usar. O [Emacs] tem o recurso de indentação baseado em expressão
+regular. Para aplicá-lo aos sinais de igual, selecione o texto e dê `M-x
+align-regexp RET = RET` (`RET` é pressionar Enter). Você pode, se usar
 isso com frequência, criar um *key binding* para uma função que faça
 isso no código selecionado.
 
-```
+```lisp
 (defun columnate-at-R-assign-operator ()
   "Função que alinha a região com a primeira ocorrência de sinais
    ` <- ' e ` = '. Baseado em:
@@ -320,11 +371,10 @@ isso no código selecionado.
 ## Vírgulas ##
 
 Vírgulas devem ser seguidas de espaço, exceto para as de final de
-linha. Elas não dever ser precedidas de espaço, exceto quando precedidas
-por outra vírgulas dentro dos colchetes.
+linha. Elas não devem ser precedidas de espaço, exceto quando precedidas
+por outra vírgula dentro dos colchetes de seleção.
 
-```{r, eval=FALSE}
-# dput(sample(names(precip), 20))
+```r
 # Bom.
 EyeHairColor[, , 2]
 x <- c("Nashville", "Seattle Tacoma", "Wilmington", "Boise", "Raleigh",
@@ -352,13 +402,14 @@ texto.
 
 Costuma-se usar 80 ou 72 espaços como comprimento máximo de linha, sendo
 este último ligeiramente mais adequado para trabalhar com *script* e
-*console* lado a lado.
+*console* lado a lado nos monitores de resolução atuais.
 
 No [Emacs], para comodidade, pode-se habilitar o quebrar linhas
-automaticamente (`M-x auto-fill-mode`). Caso não goste, pode apenas
-habilidar o destaque com cores para linhas que excedem os limites.
+automaticamente (`M-x auto-fill-mode`). Caso não goste, como muitos que
+acham um pouco desastroso, pode apenas habilidar o destaque com cores
+para linhas que excedem os limites.
 
-```
+```lisp
 ;; Define o comprimento máximo de texto para a linha.
 (setq-default fill-column 72)
 
@@ -391,7 +442,7 @@ Os espaços no final de linha são desnecessários, então evite-os. No
 [Emacs] você pode habilitar a remoção automática de espaços de final de
 linha (*traling spaces*).
 
-```
+```lisp
 ;; Habilita removação de espaços de fim de linha quando salva o arquivo.
 (add-hook 'before-save-hook 'delete-trailing-whitespace)
 ```
@@ -404,7 +455,7 @@ Quando for necessário quebrar linhas em meio a operações matemáticas e
 lógicas, as linhas tem que terminar com um operador para haver
 continuidade da operação.
 
-```{r, eval=FALSE}
+```r
 # Bom.
 mean(precip,
      na.rm = TRUE)
@@ -415,7 +466,7 @@ mean(precip, na.rm =
 
 # x será apenas o resultado da soma, que é uma instrução completa.
 x <- 2 + 4 + 5
-    - 3 - 8
+- 3 - 8
 
 # Agora x será o resultado de soma e diferença.
 x <- 2 + 4 + 5 -
@@ -435,7 +486,7 @@ indentação. É sempre `#` e alinhado ao código (para quê melhor, muitos
 vão dizer). Por isso, vale o denomidador comum e usuários de [Emacs]
 podem desabilidar o padrão do [ESS].
 
-```
+```lisp
 (add-hook 'ess-mode-hook
           '(lambda()
              ;; Sem estilos de indentação.
@@ -449,52 +500,32 @@ podem desabilidar o padrão do [ESS].
 Uma boa prática, principalmente se seu código é material de ensino, é
 fazer divisões nele como se fossem seções de um artigo. Use uma marcação
 visual consistente e fácil de manter. Por anos nós usamos réguas com
-traços de tamanho 72 digitos. Para diferenciar o nível da divisão,
-usamos 3 variações: a maior (para capítulo e cabeçalho) é feita com
-sinal de igual (`=`), a média (para seção) é com traços (`-`) e a menor
-(para subseção) também, tem comprimento inferior (45 digitos). Criamos
-um *key binding* para isso no Emacs por comodidade mas se você usa outro
-editor que indique a coluna 72, pressione até preencher com o digito
-desejado. Lembre-se de preceder com um `#`.
-
-----------------------------------------------------
- Atalho        Descrição
--------------- ------------------------------------
- `Ctrol-7-1 =` Com o control pressionado digite
-               71, solte e pressione `=`. Isso vai
-               repetir o = 71 vezes.
-
- `Ctrol-7-1 -` Idem mas com traço.
-
- `Ctrol-4-4 -` Idem mas repetindo 44 vezes.
-----------------------------------------------------
-
-: Atalhos no Emacs e sua descrição para fazer divivões horizontais no
-código.
-
-```{r, eval=FALSE}
+traços de tamanho 72 digitos e acreditamos ser uma das melhores
+opções. Muitos usam divisões com o sinal de comentários, #, mas
+acreditamos ficar carregado devido ao caracter ser volumoso.
+
+Para diferenciar o nível da divisão, usamos 3 variações: a maior (para
+capítulo e cabeçalho) é feita com sinal de igual (`=`), a média (para
+seção) é com traços (`-`) e a menor (para subseção) também, tem
+comprimento inferior (45 digitos). Criamos um *key binding* para isso no
+Emacs por comodidade mas se você usa outro editor que indique a coluna
+72, pressione até preencher com o digito desejado. Lembre-se de preceder
+com um `#`.
+
+ * `Ctrol-7-1 =`: Com o control pressionado digite 71, solte e pressione
+    `=`. Isso vai repetir o = 71 vezes.
+ * `Ctrol-7-1 -`: Idem mas com traço.
+ * `Ctrol-4-4 -`: Idem mas repetindo 44 vezes.
+
+```r
 #=======================================================================
-# (Título) Ajuste de modelos não lineares para crescimento vegetal.
+# (Título)
 
 #-----------------------------------------------------------------------
-# (seção) Conhecendo os dados.
-
-<Carrega os dados, faz gráficos, etc.>
-
-#-----------------------------------------------------------------------
-# (seção) Ajuste do modelo logístico.
+# (seção)
 
 #-------------------------------------------
-# (subseção) Especificação.
-
-#-------------------------------------------
-# (subseção) Diagnóstico.
-
-#-----------------------------------------------------------------------
-# (seção) Ajuste do modelo de Compertz
-
-<continua>
-
+# (subseção)
 ```
 
 ## Linhas em branco ##
@@ -527,10 +558,10 @@ chaves]. No R, usamos o K&R no qual a chave que abre é o último
 character da linha precedida de espaço e a que fecha fica em linha
 exclusiva e indentada conforme o código.
 
-No R usamos chaves nas instruções de *if*, *for*, *while*, *function* e
-nas funções *with*, *switch*, por exemplo.
+No R usamos chaves nas instruções de *if*, *for*, *while*, *repeat* e
+*function* e nas funções *with*, *switch* e *replicate*, por exemplo.
 
-```{r, eval=FALSE}
+```r
 pitagoras <- function(a, b) {
     h <- sqrt(a^2 + b^2)
 }
@@ -579,7 +610,7 @@ No R, não se coloca espaço entre os parenteses e seu conteúdo. Existe
 espaço ao redor do par de parênteses nas instruções de *if*, *for* e
 *while*.
 
-```{r, eval=FALSE}
+```r
 # Bom.
 if (x %% 2 == 0) {
     print("x é par.")
@@ -597,7 +628,7 @@ Ponto e vírgula no R serve para separar instruções na mesma linha,
 funcionando como uma quebra visual de linha. No entanto, não se
 recomenda o seu uso.
 
-```{r, eval=FALSE}
+```r
 # Bom.
 library(car)
 library(gdata)
@@ -607,21 +638,21 @@ library(lattice)
 library(car); library(gdata); library(lattice)
 ```
 
-## Documentação de funções na função ##
+## Documentação embutida de funções ##
 
-Uma prática muito valorizada e útil é documentar as funções que você
-cria. A documentação serve de lembrete para você no futuro e é intrução
-para as pessoas que usam o seu código. Abaixo a função *baskara* foi
-documentada de duas formas diferentes. A primeira é uma forma livre
-enquanto que a segunda usa as *tags* do roxygen2. Se você escreve uma
-função e tem intenção de incluí-la em um pacote, o segundo padrão é mais
+Uma prática muito valorizada é documentar as funções que você cria. A
+documentação serve de lembrete para você no futuro e é instrução para as
+pessoas que usam o seu código. Abaixo a função *baskara* foi documentada
+de duas formas diferentes. A primeira é uma forma livre enquanto que a
+segunda usa as *tags* do [`roxygen2`]. Se você escreve uma função e tem
+intenção de incluí-la em um pacote, o segundo padrão é mais
 interessante.
 
 Perceba que esse exemplo é bem minimalista pois apenas documenta os
 *inputs* e o *output* da função. Na impede de detalhes serem
 adicionados.
 
-```{r}
+```r
 # Função documentada de forma livre.
 baskara <- function(a, b, c) {
     # a,b,c: (numeric) coeficientes da equação de segundo grau
@@ -655,8 +686,11 @@ retorna *FALSE* se não conseguir enquanto que `library()` retorna
 [ESS]: http://ess.r-project.org/Manual/ess.html
 [RStudio]: https://www.rstudio.com/
 [Emacs]: https://www.gnu.org/software/emacs/
-[mcglm]: http://git.leg.ufpr.br/wbonat/mcglm
+[mcglm]: https://github.com/wbonat/mcglm
 [car]: http://www.rdocumentation.org/packages/car
 [devtools]: http://www.rdocumentation.org/packages/devtools
 [estilos de emprego de chaves]: https://en.wikipedia.org/wiki/Indent_style
 [Yihui Xie]: http://yihui.name/en/2014/07/library-vs-require/
+[Hadley Wickham]: http://hadley.nz/
+[John Fox]: http://socserv.mcmaster.ca/jfox/
+[`roxygen2`]: https://cran.r-project.org/web/packages/roxygen2/roxygen2.pdf
diff --git a/plano.md b/plano.md
index 2f1d02b5dac500622de17f6598f555f2ccac7cab..3181137b19ad69ddd86864c50aaed5b97ba1bacf 100644
--- a/plano.md
+++ b/plano.md
@@ -19,10 +19,24 @@ atividades propostas para cada semana e integrante. Cada coluna da
 tabela, com exceção da que apresenta os integrantes e os "mergeadores",
 mostra o *status* e o respectivo MR (*Merge Request*) solicitado para
 incorporar a realização das atividades propostas no ramo `devel` do
-projeto. Para facitar a visualização o *emoji* :white\_check\_mark:,
+projeto. Para facilitar a visualização o *emoji* :white\_check\_mark:,
 representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 
-<table>
+<table style="width:335%;">
+<colgroup>
+<col width="33%" />
+<col width="15%" />
+<col width="40%" />
+<col width="40%" />
+<col width="40%" />
+<col width="40%" />
+<col width="40%" />
+<col width="40%" />
+<col width="11%" />
+<col width="11%" />
+<col width="11%" />
+<col width="11%" />
+</colgroup>
 <thead>
 <tr class="header">
 <th align="left">Contribuidor</th>
@@ -47,8 +61,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!13</td>
 <td align="center">:white_check_mark: / MR!25</td>
 <td align="center">:x: / -</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:white_check_mark: / MR!39</td>
+<td align="center">:white_check_mark: / MR!49</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -61,22 +75,22 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:x: / -</td>
+<td align="center">:x: / -</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 </tr>
 <tr class="odd">
-<td align="left">Angela L. C. Legey</td>
+<td align="left">Ângela L. C. Legey</td>
 <td align="left">Cesar</td>
 <td align="center">:white_check_mark: / MR!2</td>
 <td align="center">:white_check_mark: / MR!15</td>
 <td align="center">:white_check_mark: / MR!23</td>
 <td align="center">:white_check_mark: / MR!30</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:white_check_mark: / MR!37</td>
+<td align="center">:white_check_mark: / MR!44</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -89,8 +103,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!11</td>
 <td align="center">:white_check_mark: / MR!17</td>
 <td align="center">:white_check_mark: / MR!32</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:x: / -</td>
+<td align="center">:x: / -</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -103,8 +117,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!22</td>
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:x: / -</td>
+<td align="center">:x: / -</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -117,8 +131,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!27</td>
 <td align="center">:x: / -</td>
 <td align="center">:white_check_mark: / MR!31</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:white_check_mark: / MR!38</td>
+<td align="center">:white_check_mark: / MR!46</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -131,8 +145,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!14</td>
 <td align="center">:white_check_mark: / MR!21</td>
 <td align="center">:white_check_mark: / MR!35</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:white_check_mark: / MR!41</td>
+<td align="center">:x: / -</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -143,14 +157,14 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="left">Cesar</td>
 <td align="center">:white_check_mark: / MR!5</td>
 <td align="center">:white_check_mark: / MR!19</td>
+<td align="center">:x: / MR!36</td>
+<td align="center">:x: / MR!48</td>
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
 </tr>
 <tr class="odd">
 <td align="left">Jhenifer C. Veloso</td>
@@ -159,22 +173,22 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!16</td>
 <td align="center">:white_check_mark: / MR!26</td>
 <td align="center">:white_check_mark: / MR!29</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:white_check_mark: / MR!40</td>
+<td align="center">:white_check_mark: / MR!47</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 </tr>
 <tr class="even">
-<td align="left">Monica L. H. Oliveira</td>
+<td align="left">Mônica L. H. Oliveira</td>
 <td align="left">Walmes</td>
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
 <td align="center">:x: / -</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:x: / -</td>
+<td align="center">:x: / -</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -187,8 +201,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!20</td>
 <td align="center">:white_check_mark: / MR!24</td>
 <td align="center">:white_check_mark: / MR!33</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:x: / -</td>
+<td align="center">:x: / MR!45</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -201,8 +215,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">:white_check_mark: / MR!18</td>
 <td align="center">:white_check_mark: / MR!28</td>
 <td align="center">:white_check_mark: / MR!34</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">:white_check_mark: / MR!41</td>
+<td align="center">:white_check_mark: / MR!50</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -215,8 +229,8 @@ representa que o trabalho foi REALIZADO e :x: o NÃO REALIZADO.
 <td align="center">-</td>
 <td align="center">-</td>
 <td align="center">-</td>
-<td align="center">. / .</td>
-<td align="center">. / .</td>
+<td align="center">-</td>
+<td align="center">-</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
 <td align="center">. / .</td>
@@ -242,23 +256,101 @@ indicado:
 <!-- mais antiga. -->
 <!--------------------------------------------- -->
 <!-- * **Semana 10 - (03/05 - 10/05)** -->
-<!--     + **Alcides Conte Neto** -->
-<!--     + **Altamiro Antonio Basiewics** -->
-<!--     + **Angela Luiza Cunha Legey** -->
-<!--     + **Bruna Davies Wundervald** -->
+<!--     + **Alcides C. Neto** -->
+<!--     + **Altamiro A. Basiewics** -->
+<!--     + **Ângela L. C. Legey** -->
+<!--     + **Bruna D. Wundervald** -->
 <!--     + **Bruno Geronymo** -->
 <!--     + **Daniel Ikenaga** -->
-<!--     + **Eduardo Elias Ribeiro Junior** -->
-<!--     + **Gabriel Sartori Klostermann** -->
-<!--     + **Jhenifer Caetano Veloso** -->
-<!--     + **Monica Ludmila Hintz De Oliveira** -->
-<!--     + **Paula Alessandra Zeizer Dimas** -->
-<!--     + **Walmes Marques Zeviani** -->
-<!--     + **Cesar Augusto Taconeli** -->
+<!--     + **Eduardo E. R. Junior** -->
+<!--     + **Gabriel S. Klostermann** -->
+<!--     + **Jhenifer C. Veloso** -->
+<!--     + **Mônica L. H. De Oliveira** -->
+<!--     + **Paula A. Z. Dimas** -->
+<!--     + **Walmes M. Zeviani** -->
+<!--     + **Cesar A. Taconeli** -->
 <!-- * **Semana 9 - (26/04 - 03/05)** -->
 <!-- * **Semana 8 - (19/04 - 26/04)** -->
-<!-- * **Semana 7 - (12/04 - 19/04)** -->
-<!-- * **Semana 6 - (05/04 - 12/04)** -->
+-   **Semana 7 - (12/04 - 19/04)**
+    -   **Alcides C. Neto**: Listar as tabelas e incluir, no GitLab as
+        *issues* do livro Planejamento e Analise Estatistica de
+        Experimentos Agronomicos - Decio Barbin, junto ao Walmes.
+    -   **Altamiro A. Basiewics**: **Concluir as atividades das CINCO
+        semanas anteriores**; e concluir a *issue* \#91 (3 tabelas)
+    -   **Ângela L. C. Legey**: Concluir a *issue* \#73 (4 tabelas)
+    -   **Bruna D. Wundervald**: **Concluir as atividades das 2 semanas
+        anteriores**; e incluir mais 1 tabela ao pacote.
+    -   **Bruno Geronymo**: **Concluir as atividades das QUATRO semanas
+        anteriores**; e concluir *issue* \#46 (5 tabelas).
+    -   **Daniel Ikenaga**: Concluir *issue* \#82 (11 tabelas).
+    -   **Eduardo E. R. Junior**: **Concluir as atividades da semana
+        anteriore**; atualizar o `plano.md`; Realizar as eventuais
+        correções de MR e incorporá-los ao ramo `devel`; e listar dados
+        e incluir as *issues* referentes a nova obra Modelos de
+        Regressão com apoio computacional - Gilberto A. Paula.
+    -   **Gabriel S. Klostermann**: **Concluir as atividades das 2
+        semanas anteriores**; e concluir *issue* \#54 (2 tabelas).
+    -   **Jhenifer C. Veloso**: Concluir a *issue* \#65 (2 tabelas).
+    -   **Mônica L. H. De Oliveira**: **Concluir as atividades das SEIS
+        semanas anteriores**; e listar as tabelas e incluir, no GitLab,
+        as *issues* referentes a uma nova obra a ser definida com o
+        tutor Walmes.
+    -   **Paula A. Z. Dimas**: Concluir a *issue* \#77 (6 tabelas)
+    -   **Walmes M. Zeviani**: Realizar as eventuais correções de MR e
+        incorporá-los ao ramo `devel`; Concluir a *issue* \#13 (2
+        tabelas); e listar, junto ao colaborador Alcides, as tabelas do
+        livro Planejamento e Analise Estatistica de Experimentos
+        Agronomicos - Decio Barbin.
+    -   **Cesar A. Taconeli**: Realizar as eventuais correções de MR e
+        incorporá-los ao ramo `devel`;e Revisar a *vignette* adicionada
+        pelo Walmes.
+
+Nesta semana alguns colaboradores relataram a dificuldade e instalar o
+pacote `devtools`. Ressaltou-se que este pacote necessita de algumas
+dependências do sistema operacional, ver \[página do RStudio\] com as
+principais informações. Ainda Jhenifer informou que há três computadores
+do PET devidamente equipados com os recursos para desenvolvimento do
+projeto, portanto os colaboradores que necessitarem podem utizá-los.
+
+-   **Semana 6 - (05/04 - 12/04)**
+    -   **Alcides C. Neto**: Concluir a issue \#53 (2 tabelas)
+    -   **Altamiro A. Basiewics**: **Concluir as atividades das QUATRO
+        semanas anteriores**; e concluir a issue \#90 (3 tabelas)
+    -   **Ângela L. C. Legey**: Concluir a issue \#72 (4 tabelas)
+    -   **Bruna D. Wundervald**: **Concluir as atividades da semana
+        anterior**; e incluir *issue* \#23 (nº de tabelas não informado
+        na *issue*).
+    -   **Bruno Geronymo**: **Concluir as atividades das TRÊS semanas
+        anteriores**; e concluir *issue* \#45 (5 tabelas).
+    -   **Daniel Ikenaga**: Concluir a *issue* \#81 (6 tabelas)
+    -   **Eduardo E. R. Junior**: Atualizar o `plano.md`; Realizar as
+        eventuais correções de MR e incorporá-los ao ramo `devel`;
+        concluir a *issue* \#32 (3 tabelas); e incluir o esboço de uma
+        *vignette* sobre regressão linear simples.
+    -   **Gabriel S. Klostermann**: **Concluir as atividades das 2
+        semanas anteriores**; e concluir *issue* \#59 (2 tabelas).
+    -   **Jhenifer C. Veloso**: Concluir *issue* \#64 (nº de tabelas não
+        informado na *issue*).
+    -   **Mônica L. H. De Oliveira**: **Concluir as atividades das CINCO
+        semanas anteriores**; e adicionar os demais *datasets* para
+        concluir a obra
+    -   **Paula A. Z. Dimas**: **Concluir o trabalho da semana anterior,
+        solicitando MR**; e concluir a *issue* \#76 (nº de tabelas não
+        informado na *issue*).
+    -   **Walmes M. Zeviani**: Realizar as eventuais correções de MR e
+        incorporá-los ao ramo `devel`; Concluir a *issue* \#12 ();
+        adicionar outra *vignette* ao pacote; e criar o ramo `baby` e
+        atualizar o `CONTRIBUTING.md` com o fluxo sob o novo ramo
+    -   **Cesar A. Taconeli**: Realizar as eventuais correções de MR e
+        incorporá-los ao ramo `devel`;e Revisar a *vignette* adicionada
+        pelo Walmes.
+
+Nesta semana Eduardo relatou sobre o tempo despendido na verificação do
+pacote devido aos vários *datasets* e que esse tempo só tende a
+aumentar. Com isso foi decidido pela criação de um ramo, sob o nome de
+`baby` sem os *datasets* mas com os arquivos `DESCRIPTION`, `.gitignore`
+e demais adicionais para funcionamento do pacote.
+
 -   **Semana 5 - (29/03 - 05/04)**
     -   **Alcides C. Neto**: **Concluir as atividades da semana
         anterior**; e adicionar mais as tabelas de dados para exercício
@@ -298,9 +390,9 @@ atividades do projeto. Porém, em reunião, comentou-se que o RStudio Web
 deve ser considerado como uma ferramenta auxiliar e que os integrantes
 devem ter, em seus computadores de trabalho, os recursos para
 desenvolvimento das atividades previstas. Para GIT recomendamos a
-leitura do segundo capítulo da [Apostila Git do PET] que fala sobre a
+leitura do segundo capítulo da \[Apostila Git do PET\] que fala sobre a
 instalação. Sobre o `devtools`, pacote R para desenvolvedores, há a
-[página do RStudio] com as principais informações.
+\[página do RStudio\] com as principais informações.
 
 -   **Semana 4 - (22/03 - 29/03)**
     -   **Alcides C. Neto**: Concluir o *issue* \#52 (5 tabelas).
@@ -313,15 +405,15 @@ instalação. Sobre o `devtools`, pacote R para desenvolvedores, há a
         suas tabelas e incluindo as respectivas *issues* no GitLab.
         (*issue* \#70).
     -   **Bruna D. Wundervald**: Concluir seus dois próximos *issues*,
-        \#18 e \#19 (realizar as atividades listadas nestes em apenas um
-        ramo).
+        \#18 e \#19 (realizar as atividades listadas nestes em apenas
+        um ramo).
     -   **Bruno Geronymo**: **Concluir as atividades da semana
         anterior**; e concluir *issue* \#43 (5 tabelas).
     -   **Daniel Ikenaga**: **Concluir as atividades da semana
         anterior**; e incluir 4 tabelas. (*issue* \#79).
     -   **Eduardo E. R. Junior**: Realizar as eventuais correções de MR
-        e incorporá-los ao ramo `devel`; e concluir o *issue* \#30 (2
-        tabelas).
+        e incorporá-los ao ramo `devel`; e concluir o *issue* \#30
+        (2 tabelas).
     -   **Gabriel S. Klostermann**: **Concluir as atividades da semana
         anterior**; e concluir *issue* \#60 (2 tabelas).
     -   **Jhenifer C. Veloso**: Concluir *issue* \#62 (5 tabelas).
@@ -332,8 +424,8 @@ instalação. Sobre o `devtools`, pacote R para desenvolvedores, há a
         suas tabelas e incluindo as respectivas *issues* no GitLab.
         (*issue* \#69).
     -   **Walmes M. Zeviani**: Realizar as eventuais correções de MR e
-        incorporá-los ao ramo `devel`; e concluir o *issue* \#10 (4
-        tabelas).
+        incorporá-los ao ramo `devel`; e concluir o *issue* \#10
+        (4 tabelas).
     -   **Cesar A. Taconeli**: Realizar as eventuais correções de MR e
         incorporá-los ao ramo `devel`.
 -   **Semana 3 - (15/03 - 22/03)**
@@ -351,13 +443,13 @@ instalação. Sobre o `devtools`, pacote R para desenvolvedores, há a
         anterior**; incluir mais 4 tabelas; e criar os demais *issues*
         referentes às tabelas de dados simulados e/ou de exercícios.
     -   **Eduardo E. R. Junior**: Realizar as eventuais correções de MR
-        e incorporá-los ao ramo `devel`; e concluir o *issue* \#29 (3
-        tabelas).
+        e incorporá-los ao ramo `devel`; e concluir o *issue* \#29
+        (3 tabelas).
     -   **Gabriel S. Klostermann**: Incluir 2 tabelas; e adicionar os
-        arquivos-fonte (.txt) de todas as tabelas da obra sob sua
-        responsabilidade.
-    -   **Jhenifer C. Veloso**: Incluir as tabelas do capítulo 7 (3
-        tabelas).
+        arquivos-fonte (.txt) de todas as tabelas da obra sob
+        sua responsabilidade.
+    -   **Jhenifer C. Veloso**: Incluir as tabelas do capítulo 7
+        (3 tabelas).
     -   **Monica L. H. Oliveira**: **Concluir as atividades das 2
         semanas anteriores**; e incluir 1 tabela.
     -   **Paula A. Z. Dimas**: Concluir *issues* \#36, \#37 e \#38, 3
@@ -387,8 +479,8 @@ instalação. Sobre o `devtools`, pacote R para desenvolvedores, há a
         incluir 2 ou 3 tabelas; e Checar o *build* de verificação do
         pacote (para correção do erro gerado no seu ramo).
     -   **Eduardo E. R. Junior**: Realizar as eventuais correções de MR
-        e incorporá-los ao ramo `devel`; e concluir o *issue* \#28 (3
-        tabelas).
+        e incorporá-los ao ramo `devel`; e concluir o *issue* \#28
+        (3 tabelas).
     -   **Gabriel S. Klostermann**: Listar todas as tabelas presente na
         obra de sua responsabilidade; criar os respectivos *issues* no
         GitLab; e incluir 2 tabelas.
@@ -413,84 +505,115 @@ instalação. Sobre o `devtools`, pacote R para desenvolvedores, há a
 Lista de datasets
 -----------------
 
-Até o momento, no ramo `devel` temos 94 conjuntos de dados já
+Até o momento, no ramo `devel` temos 123 conjuntos de dados já
 devidamente incluídos, documentados e revisados. Abaixo a contagem de
 *datasets* por obra.
 
-<table>
+<table style="width:104%;">
+<colgroup>
+<col width="16%" />
+<col width="29%" />
+<col width="33%" />
+<col width="25%" />
+</colgroup>
 <thead>
 <tr class="header">
 <th align="left">Livros</th>
 <th align="center">Número de datasets</th>
 <th align="center">Número de observações</th>
+<th align="left">Tamanho em disco</th>
 </tr>
 </thead>
 <tbody>
 <tr class="odd">
 <td align="left">Banzatto</td>
-<td align="center">12</td>
-<td align="center">1296</td>
+<td align="center">19</td>
+<td align="center">2648</td>
+<td align="left">48.273 Kb</td>
 </tr>
 <tr class="even">
 <td align="left">Charnet</td>
 <td align="center">10</td>
 <td align="center">1575</td>
+<td align="left">16.602 Kb</td>
 </tr>
 <tr class="odd">
 <td align="left">Costa</td>
-<td align="center">2</td>
-<td align="center">132</td>
+<td align="center">6</td>
+<td align="center">421</td>
+<td align="left">11.938 Kb</td>
 </tr>
 <tr class="even">
 <td align="left">Demetrio</td>
 <td align="center">18</td>
 <td align="center">801</td>
+<td align="left">22.172 Kb</td>
 </tr>
 <tr class="odd">
 <td align="left">Dias</td>
 <td align="center">2</td>
 <td align="center">143</td>
+<td align="left">0.641 Kb</td>
 </tr>
 <tr class="even">
 <td align="left">Dinorah</td>
 <td align="center">1</td>
 <td align="center">660</td>
+<td align="left">6.445 Kb</td>
 </tr>
 <tr class="odd">
+<td align="left">Epprecht</td>
+<td align="center">8</td>
+<td align="center">1120</td>
+<td align="left">12.188 Kb</td>
+</tr>
+<tr class="even">
 <td align="left">Ferreira</td>
 <td align="center">7</td>
 <td align="center">533</td>
+<td align="left">11.109 Kb</td>
 </tr>
-<tr class="even">
+<tr class="odd">
 <td align="left">Manly</td>
-<td align="center">1</td>
-<td align="center">294</td>
+<td align="center">3</td>
+<td align="center">673</td>
+<td align="left">11.773 Kb</td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td align="left">Mingoti</td>
-<td align="center">8</td>
-<td align="center">2150</td>
+<td align="center">10</td>
+<td align="center">2750</td>
+<td align="left">29.031 Kb</td>
 </tr>
-<tr class="even">
+<tr class="odd">
 <td align="left">Pimentel</td>
 <td align="center">7</td>
 <td align="center">422</td>
+<td align="left">14.969 Kb</td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td align="left">Ramalho</td>
-<td align="center">10</td>
-<td align="center">1194</td>
+<td align="center">13</td>
+<td align="center">5274</td>
+<td align="left">47.039 Kb</td>
+</tr>
+<tr class="odd">
+<td align="left">Ramos</td>
+<td align="center">3</td>
+<td align="center">114</td>
+<td align="left">3.141 Kb</td>
 </tr>
 <tr class="even">
 <td align="left">Zimmermann</td>
 <td align="center">16</td>
 <td align="center">5107</td>
+<td align="left">64.953 Kb</td>
 </tr>
 </tbody>
 </table>
 
 [Retornar à tabela de conteúdo](#painel-de-atividades-do-labestdata)
-[Apostila Git do PET]:
+\[Apostila Git do PET\]:
 <https://gitlab.c3sl.ufpr.br/pet-estatistica/apostila-git/blob/devel/apostila_git.pdf>
-[página do RStudio]:
+\[página do RStudio\]:
 <https://www.rstudio.com/products/rpackages/devtools/>