You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@accumulo.apache.org by dl...@apache.org on 2023/02/24 20:59:15 UTC
[accumulo] branch main updated: Enable Github wiki in asf.yaml
This is an automated email from the ASF dual-hosted git repository.
dlmarion pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/accumulo.git
The following commit(s) were added to refs/heads/main by this push:
new ae8a817e7b Enable Github wiki in asf.yaml
ae8a817e7b is described below
commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
Author: Dave Marion <dl...@apache.org>
AuthorDate: Fri Feb 24 15:59:10 2023 -0500
Enable Github wiki in asf.yaml
---
.asf.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.asf.yaml b/.asf.yaml
index bc2c943e82..08aa357082 100644
--- a/.asf.yaml
+++ b/.asf.yaml
@@ -27,7 +27,7 @@ github:
- big-data
- hacktoberfest
features:
- wiki: false
+ wiki: true
issues: true
projects: true
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher Shannon <ch...@gmail.com>.
I am +1 on the idea of using some sort of Wiki (either Github or
Apache confluence cwiki) for design discussions and related docs. A
wiki is so much easier to update information quickly rather than
trying to use SVN or the website repo and when working on design
changes as document updates can happen pretty quickly when
collaborating. It's also super easier to view the edit history, etc.
In terms of the web site, I've always viewed a project's website as
more customer facing than for core project developers. Obviously the
website can host whatever we want but in my opinion I think a website
is best served as a place that gives information about the project,
official documentation, news/updates, contact information, etc. which
is what most projects (not just Apache) do. We can always have a link
on the website for the wiki for development.
If there is a concern about github wiki not being backed up then as
Dave mentioned I think the Apache wiki is a good alternative. For
example, Kafka hosts all of their design proposals and discussion on
Cwiki: https://cwiki.apache.org/confluence/display/kafka/kafka+improvement+proposals
which makes it easier to track history and edit quickly.
On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
>
> I reverted the change. I didn't think it would be a big deal, but if it requires discussion, then let's discuss it.
>
> I'm looking for a place to host information related to internal design discussions. I envision these to be living documents that will be updated over time as the design/implementation progresses and that other committers will be able to comment on and edit. I don't feel that the website is the correct place for this because:
>
> 1. I don't think internal design discussions should go on the project website.
> 2. Changes to the design documents could not be seen by others right away (IIRC changes to the website are built and available at https://accumulo.staged.apache.org/, but human intervention is required to publish it at https://accumulo.apache.org/).
>
> I looked in the INFRA issues and other projects are using the GH Wiki feature and I saw no mention of backing it up or the requirement to do so (maybe they rely on GitHub backing it up?). It does appear that we would need an INFRA ticket so that they can modify the GitHub project settings to lock the GitHub wiki down so that only committers can modify it. If GitHub Wiki is not acceptable, then I think Apache Confluence (https://cwiki.apache.org) might be an acceptable alternative.
>
> -----Original Message-----
> From: Christopher <ct...@apache.org>
> Sent: Saturday, February 25, 2023 4:41 AM
> To: accumulo-dev <de...@accumulo.apache.org>
> Cc: commits@accumulo.apache.org
> Subject: Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml
>
> I don't recall a discussion about this change, but I think it goes against previous efforts to make the website the one canonical location for our documentation. I don't even think infra is backing up wiki repos, so there wouldn't even be a record of the wiki contents in ASF spaces (vs. the main repo, which is backed up to GitBox and the issue tracker, which CCs the notifications list).
>
> In short, I think this should be reverted and we should not use the GitHub wiki. If we need to store documents in a version controlled way, we can store them on the website, or in our project's SVN dev space. The wiki is just another place people would have to follow if they want to participate, and I don't think that serves us. Therefore, I think we shouldn't use it.
>
>
> On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > dlmarion pushed a commit to branch main in repository
> > https://gitbox.apache.org/repos/asf/accumulo.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > described below
> >
> > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > Author: Dave Marion <dl...@apache.org>
> > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> >
> > Enable Github wiki in asf.yaml
> > ---
> > .asf.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/.asf.yaml b/.asf.yaml
> > index bc2c943e82..08aa357082 100644
> > --- a/.asf.yaml
> > +++ b/.asf.yaml
> > @@ -27,7 +27,7 @@ github:
> > - big-data
> > - hacktoberfest
> > features:
> > - wiki: false
> > + wiki: true
> > issues: true
> > projects: true
> >
> >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Daniel Roberts <dd...@gmail.com>.
The discussions on the mailing list are important, but visual aids in
mailing lists seem like they would be problematic.
Likewise, it has been noted in other threads that email clients can cause
complications with discussion threading so that could raise issues with
long-lived discussion topics.
https://lists.apache.org/thread/sd9zxkqyj98f9mh49h3j1pgt7b935qrc
I dislike the website discussion area idea as it seems to add a technical
hurdle due to formatting.
Unless I'm mistaken, any graphics or visual aids would be required to be
located where website rendering code can load them and reference them into
the page.
Doesn't this mean that a contributor would be required to render the
website locally to view all contextual information in order to view and
comment accurately?
Otherwise, the accumulo-website repo would need to allow changes to the
design space to be committed and rendered publicly before review.
That doesn't seem like an ideal solution.
You could put all that information into a github issue with proper
formatting in addition to the website file changes.
However, this would mean that any sort of topic threading would result in
per-line comments on files in that github issue and long-lived PR reviews.
I could see this increasing notification counts in github and not being
ideal.
Overall, both options seem like a large amount of effort vs using a wiki
(github or confluence based).
I am a fan of using the github wiki for now until the cwiki creation is
resolved. It unblocks progress and we can always pivot later.
Have we confirmed with INFRA that the github wiki is not backed up? It is a
git repo and able to be cloned locally, so backup is technically possible.
On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com> wrote:
> I'm opposed to using the website for the reasons I specified earlier, so it
> looks like we need to
> wait for INFRA to fix Confluence. I'd be curious how much we need to use
> the mailing list during
> the design phase. We can announce meeting dates/times on the mailing list
> and post links to
> meeting notes in Confluence. Ultimately, decisions made by the people that
> want to be involved
> will turn into pull requests against the codebase which comitters can weigh
> in on. When you say,
> "... but decisions about those would still need to be done on the mailing
> list." Are you saying that
> we need to discuss every single design decision on the mailing list?
>
> On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org> wrote:
>
> > So, I agree a space would be helpful. Although it's old school and
> > inconvenient, the mailing list is the canonical place for discussion.
> > We currently use GitHub issues a lot, but that's copied to a mailing
> > list (as is our old JIRA space), so if people want to participate
> > without a GitHub account, they can still do that. There are certain
> > options that are perhaps less convenient, such as just using the
> > mailing list and our dev SVN space, but still more appropriate than
> > options that would be less ubiquitous for potential participants.
> >
> > I think the ASF Confluence is probably fine, for storing, editing, and
> > collaborating on shared documents, but decisions about those would
> > still need to be done on the mailing list. If I remember correctly, we
> > used to have a Wiki space, prior to it being transferred to
> > Confluence, but it was poorly maintained, so we abandoned it in favor
> > of using the website for docs. I could be mis-remembering, but I think
> > this is the case. It might explain why you can't create a Confluence
> > space.
> >
> > My preference would be to just use the website. I think it's fine to
> > have a dev / design area of the website, and we can discuss on GitHub
> > issues for the accumulo-website repo. That is a bit less convenient
> > than Confluence if it's used heavily, but it's more convenient in the
> > sense that it's more accessible and fits more in line with our current
> > mode of operation. Plus, when a document is final, it's easy to link
> > to from our documentation, without making users jump to another
> > service to view docs.
> >
> > I would be opposed to using GitHub wiki or a new git repo. We have
> > enough repos. Although it seems like they are free, there is still a
> > lot of boilerplate work to maintain them, from managing
> > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > README, to keeping copyright dates updated in the NOTICE file, and
> > more.
> >
> > In summary, my preference:
> >
> > 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> > list (strongly preferred)
> > 2. Confluence, discuss on mailing list (prefer over other options, but
> > not a fan)
> > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use this
> > option)
> > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > prefer not to use this option)
> >
> > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org> wrote:
> > >
> > > Currently, asf cannot create new wiki's because of a Confluence issue (
> > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with infra
> > and in response they created that issue.
> > >
> > > To expand on this discussion, I would like to toss out another
> > alternative to discuss / explore. What if we used a separate GitHub
> > project, something like Accumulo-Design, just like accumulo-proxy and
> > accumulo-examples. As a separate project, it would be available for
> > collaboration for the community, but remain separate from main project
> and
> > the website to keep current code / documentation / design clearly
> separate
> > from speculative design discussions. As a project:
> > >
> > > - document history would be preserved with git commit history.
> > > - document collaboration could be done with normal PR submissions /
> > reviews.
> > > - issues could be used to discuss design aspects, capturing the comment
> > history.
> > >
> > > The biggest downside is that it would be yet another project to follow
> /
> > track.
> > >
> > > For me, I think the issue is that we need a public, collaborative space
> > to hold design discussions. Neither the main project or the web-site seem
> > quite appropriate and Confluence seems to lack the collaboration that can
> > be achieved with github.
> > >
> > > We need a space to capture the redesign and whatever we select can be
> > made to work - I'm just wondering what provides the easiest forum to
> build
> > a collaborative space for the Accumulo community.
> > >
> > > Ed Coleman
> > >
> > >
> > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > Circling back on this issue - I agree that comments and such make
> > sense for internal design documents. I'm going to create an INFRA ticket
> > for a cwiki space for Accumulo unless there are any objections.
> > > >
> > > > -----Original Message-----
> > > > From: Drew Farris <dr...@ill.org>
> > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > To: dev@accumulo.apache.org
> > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >
> > > > As mentioned, wikis can provide a streamlined collaborative editing
> > workflow that's less labor intensive than updating a website. They can
> > promote collaboration by providing specific tooling to support comments,
> > revisions and iteration.
> > > >
> > > > In terms of preservation, GH wikis act just like any other Git
> > repository, with a remote at (for example) git@github.com:
> > apache/accumulo.wiki.git
> > > > IIRC the pages are just GH flavored markdown. There are at least a
> few
> > Apache projects using them.
> > > >
> > > > However, GH wikis lack some features that I feel are important to
> > support collaborative authoring. For example, the ability to comment and
> > discuss specific passages in a document is a feature that's present in
> > Cwiki, but not in GH wikis. I've come appreciate this this in my google
> > docs and office workflows, so expect that it would be useful for Accumulo
> > design discussions too.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org>
> > wrote:
> > > >
> > > > > I would like to try a wiki for design documents, I think it would
> be
> > > > > less cumbersome than the website and we can always link from the
> > > > > website and issues to the wiki. I think its ok to give it a try
> and
> > > > > abandon it in the future, if abandoned would just need to properly
> > > > > communicate that. The content should be archived in Apache
> > > > > infrastructure, so if GH wiki does not do that then we should not
> use
> > > > > it. If GH wiki is not an option then could try cwiki.
> > > > >
> > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > > > >
> > > > > > I reverted the change. I didn't think it would be a big deal, but
> > if
> > > > > > it
> > > > > requires discussion, then let's discuss it.
> > > > > >
> > > > > > I'm looking for a place to host information related to internal
> > > > > > design
> > > > > discussions. I envision these to be living documents that will be
> > > > > updated over time as the design/implementation progresses and that
> > > > > other committers will be able to comment on and edit. I don't feel
> > > > > that the website is the correct place for this because:
> > > > > >
> > > > > > 1. I don't think internal design discussions should go on the
> > > > > > project
> > > > > website.
> > > > > > 2. Changes to the design documents could not be seen by others
> > > > > > right
> > > > > away (IIRC changes to the website are built and available at
> > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > > required to publish it at https://accumulo.apache.org/).
> > > > > >
> > > > > > I looked in the INFRA issues and other projects are using the GH
> > > > > > Wiki
> > > > > feature and I saw no mention of backing it up or the requirement to
> > do
> > > > > so (maybe they rely on GitHub backing it up?). It does appear that
> we
> > > > > would need an INFRA ticket so that they can modify the GitHub
> project
> > > > > settings to lock the GitHub wiki down so that only committers can
> > > > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > > > Confluence (
> > > > > https://cwiki.apache.org) might be an acceptable alternative.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christopher <ct...@apache.org>
> > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > Cc: commits@accumulo.apache.org
> > > > > > Subject: Re: [accumulo] branch main updated: Enable Github wiki
> in
> > > > > asf.yaml
> > > > > >
> > > > > > I don't recall a discussion about this change, but I think it
> goes
> > > > > against previous efforts to make the website the one canonical
> > > > > location for our documentation. I don't even think infra is backing
> > up
> > > > > wiki repos, so there wouldn't even be a record of the wiki contents
> > in
> > > > > ASF spaces (vs. the main repo, which is backed up to GitBox and the
> > > > > issue tracker, which CCs the notifications list).
> > > > > >
> > > > > > In short, I think this should be reverted and we should not use
> the
> > > > > GitHub wiki. If we need to store documents in a version controlled
> > > > > way, we can store them on the website, or in our project's SVN dev
> > > > > space. The wiki is just another place people would have to follow
> if
> > > > > they want to participate, and I don't think that serves us.
> > Therefore,
> > > > > I think we shouldn't use it.
> > > > > >
> > > > > >
> > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > >
> > > > > > > This is an automated email from the ASF dual-hosted git
> > repository.
> > > > > > >
> > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > >
> > > > > > >
> > > > > > > The following commit(s) were added to refs/heads/main by this
> > push:
> > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b
> is
> > > > > > > described below
> > > > > > >
> > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > >
> > > > > > > Enable Github wiki in asf.yaml
> > > > > > > ---
> > > > > > > .asf.yaml | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > > > > > 100644
> > > > > > > --- a/.asf.yaml
> > > > > > > +++ b/.asf.yaml
> > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > - big-data
> > > > > > > - hacktoberfest
> > > > > > > features:
> > > > > > > - wiki: false
> > > > > > > + wiki: true
> > > > > > > issues: true
> > > > > > > projects: true
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Daniel Roberts <dd...@gmail.com>.
I can confirm that apache confluence accounts can be requested and obtained
without being an ASF member.
There also seems to be a mechanism to allow write access as well.
https://cwiki.apache.org/confluence/display/INFRA/Managing+permissions+on+your+project%27s+Confluence+Space
I don't have the ability to comment on confluence pages, but I am more than
happy to use the mailing list for questions and feedback.
On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com> wrote:
> I don't see the website as an area where we would have collaborative
> discussions about an idea. For example, making comments and suggestions on
> a document like you can do in Google Docs. I see the website as a place
> where items are documented for user consumption after everything has been
> finalized. I'm not trying to create a private discussion area, I think
> anyone can see the wiki (but I think anonymous comments are disabled due to
> spam issues). I see no issue with putting work-in-progress documents on a
> wiki and referencing them via emails to the dev list. I think this is done
> in a lot of other projects. Non-committers that don't have access to the
> wiki and want to make comments, suggestions, and ask questions can do so
> via the mailing list. I think it's also possible that people can get
> confluence accounts (see https://issues.apache.org/jira/browse/INFRA-7058
> ),
> so if a non-committer wanted to participate they could.
>
> On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org> wrote:
>
> > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com> wrote:
> > >
> > > I'm opposed to using the website for the reasons I specified earlier,
> so
> > it
> >
> > Your reasons that I saw were:
> >
> > > 1. I don't think internal design discussions should go on the project
> > website.
> >
> > That doesn't look to me like a reason. That appears to just be stating
> > the conclusion. Did I miss your reason here?
> >
> > > 2. Changes to the design documents could not be seen by others right
> > away (IIRC changes to the website are built and available at
> > https://accumulo.staged.apache.org/, but human intervention is required
> > to publish it at https://accumulo.apache.org/).
> >
> > What do you mean by "others" here? Do you mean "users", as opposed to
> > "developers/contributors"? The ASF draws a distinction between
> > "developers/contributors" and "users" as it pertains to official
> > releases. Releases are intended to be consumed by users, and
> > pre-release stuff is intended to be collaborative, open to all
> > potential developers/contributors. Very very rarely are things
> > reserved exclusively for committers. We don't even have a private
> > committers space (the private mailing list is PMC-private, not
> > committer-private). Having a distinction between users and developers
> > doesn't mean we can't publish things on the website... it just means
> > that we should be careful about how we do it, which is the same care
> > we should take regardless of where we put it. Specifically, the care
> > we need to take is to avoid marketing pre-release content to users.
> > One way we can exercise this care for content on our website is that
> > we can avoid sharing these unpolished designs by simply not linking
> > them on the site, or by placing them in an area that is clearly marked
> > as intended for devs. But, we have no similar distinction between
> > committers and non-committer devs for which we should avoid sharing
> > pre-release content under development. In fact, it is the opposite...
> > we should be developing openly so as to allow room for non-committers
> > to become committers through participation in development activities.
> >
> > As for the staging/publication of the website, that's just a mechanic
> > for verifying the website isn't broken before we serve it. It's not a
> > mechanism for keeping things internal vs. shared and doesn't have
> > anything to do with the separation between devs and users. We already
> > publish Draft contents to the website, as well as developer-specific
> > documentation not intended for users.
> >
> > We've even specifically published work-in-progress design documents
> > there, of the same type that seems to be the basis of this
> > conversation (https://accumulo.apache.org/design/system-snapshot). I
> > would strongly prefer us to continue to do it this way, rather than
> > create a new space, and have these kinds of things scattered in
> > multiple places.
> >
> > If, on the other hand, you intend to say that these should be private
> > because they aren't ready for other potential contributors, then I
> > would argue that we're an openly developed project... if something
> > isn't ready to be shared with other potential contributors /
> > developers, such that you want to keep it internal to existing
> > committers, then it's not ready to be contributed to the project at
> > all... because we don't restrict collaboration to only existing
> > committers. That would prevent others from participating and earning
> > the merit to become committers, and that's not something we should be
> > doing. Anything that is okay to share with existing committers should
> > be okay to share to other potential contributors who want to
> > participate, and should be done in a space that allows them to do
> > that. The website is a perfect space for that, and has everything we
> > need. I'm actually not sure about Confluence... I suspect
> > non-committers wouldn't be able to participate there because they
> > probably can't get accounts for it.
> >
> >
> > > looks like we need to
> > > wait for INFRA to fix Confluence. I'd be curious how much we need to
> use
> > > the mailing list during
> > > the design phase. We can announce meeting dates/times on the mailing
> list
> > > and post links to
> > > meeting notes in Confluence. Ultimately, decisions made by the people
> > that
> > > want to be involved
> > > will turn into pull requests against the codebase which comitters can
> > weigh
> > > in on. When you say,
> > > "... but decisions about those would still need to be done on the
> mailing
> > > list." Are you saying that
> > > we need to discuss every single design decision on the mailing list?
> >
> > Yes and no. I am saying that decisions need to happen on the mailing
> > list, but I agree with you that this can be satisfied through pull
> > requests. I just wanted to emphasize that regardless of where we do
> > that pre-decision collaboration, that collaboration should not be
> > misconstrued as a decision to accept those ideas into the project. The
> > decision occurs during the PR or other activity that interfaces with
> > the mailing list, subsequent to the collaboration in the design/idea
> > phase.
> >
> > As for the pre-decision collaboration space we're discussing, I just
> > want to be careful that we're not creating such a space in an
> > exclusionary way that allows only existing committers to participate,
> > that excludes other potential contributors. This is still an
> > openly-developed project, and we should collaborate in a space that is
> > not exclusive to existing committers, but open to non-committer
> > contributors and potential contributors as well. So, while we may want
> > to keep a line separating dev activity from user consumption (an
> > important separation that relates to official ASF releases), we should
> > not be drawing a line between committer-devs as "internal" and
> > contributor-devs as "external". The website, with its own issue
> > tracker, the ability to render markdown, do reviews, and
> > collaboratively edit, seems like the ideal place to me. We've used it
> > before for the same purpose, and I think we should continue to do so.
> >
> >
> > >
> > > On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org>
> wrote:
> > >
> > > > So, I agree a space would be helpful. Although it's old school and
> > > > inconvenient, the mailing list is the canonical place for discussion.
> > > > We currently use GitHub issues a lot, but that's copied to a mailing
> > > > list (as is our old JIRA space), so if people want to participate
> > > > without a GitHub account, they can still do that. There are certain
> > > > options that are perhaps less convenient, such as just using the
> > > > mailing list and our dev SVN space, but still more appropriate than
> > > > options that would be less ubiquitous for potential participants.
> > > >
> > > > I think the ASF Confluence is probably fine, for storing, editing,
> and
> > > > collaborating on shared documents, but decisions about those would
> > > > still need to be done on the mailing list. If I remember correctly,
> we
> > > > used to have a Wiki space, prior to it being transferred to
> > > > Confluence, but it was poorly maintained, so we abandoned it in favor
> > > > of using the website for docs. I could be mis-remembering, but I
> think
> > > > this is the case. It might explain why you can't create a Confluence
> > > > space.
> > > >
> > > > My preference would be to just use the website. I think it's fine to
> > > > have a dev / design area of the website, and we can discuss on GitHub
> > > > issues for the accumulo-website repo. That is a bit less convenient
> > > > than Confluence if it's used heavily, but it's more convenient in the
> > > > sense that it's more accessible and fits more in line with our
> current
> > > > mode of operation. Plus, when a document is final, it's easy to link
> > > > to from our documentation, without making users jump to another
> > > > service to view docs.
> > > >
> > > > I would be opposed to using GitHub wiki or a new git repo. We have
> > > > enough repos. Although it seems like they are free, there is still a
> > > > lot of boilerplate work to maintain them, from managing
> > > > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > > > README, to keeping copyright dates updated in the NOTICE file, and
> > > > more.
> > > >
> > > > In summary, my preference:
> > > >
> > > > 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> > > > list (strongly preferred)
> > > > 2. Confluence, discuss on mailing list (prefer over other options,
> but
> > > > not a fan)
> > > > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use
> > this
> > > > option)
> > > > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > > > prefer not to use this option)
> > > >
> > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org>
> > wrote:
> > > > >
> > > > > Currently, asf cannot create new wiki's because of a Confluence
> > issue (
> > > > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with
> > infra
> > > > and in response they created that issue.
> > > > >
> > > > > To expand on this discussion, I would like to toss out another
> > > > alternative to discuss / explore. What if we used a separate GitHub
> > > > project, something like Accumulo-Design, just like accumulo-proxy
> and
> > > > accumulo-examples. As a separate project, it would be available for
> > > > collaboration for the community, but remain separate from main
> project
> > and
> > > > the website to keep current code / documentation / design clearly
> > separate
> > > > from speculative design discussions. As a project:
> > > > >
> > > > > - document history would be preserved with git commit history.
> > > > > - document collaboration could be done with normal PR submissions /
> > > > reviews.
> > > > > - issues could be used to discuss design aspects, capturing the
> > comment
> > > > history.
> > > > >
> > > > > The biggest downside is that it would be yet another project to
> > follow /
> > > > track.
> > > > >
> > > > > For me, I think the issue is that we need a public, collaborative
> > space
> > > > to hold design discussions. Neither the main project or the web-site
> > seem
> > > > quite appropriate and Confluence seems to lack the collaboration that
> > can
> > > > be achieved with github.
> > > > >
> > > > > We need a space to capture the redesign and whatever we select can
> be
> > > > made to work - I'm just wondering what provides the easiest forum to
> > build
> > > > a collaborative space for the Accumulo community.
> > > > >
> > > > > Ed Coleman
> > > > >
> > > > >
> > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > Circling back on this issue - I agree that comments and such make
> > > > sense for internal design documents. I'm going to create an INFRA
> > ticket
> > > > for a cwiki space for Accumulo unless there are any objections.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > To: dev@accumulo.apache.org
> > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > >
> > > > > > As mentioned, wikis can provide a streamlined collaborative
> editing
> > > > workflow that's less labor intensive than updating a website. They
> can
> > > > promote collaboration by providing specific tooling to support
> > comments,
> > > > revisions and iteration.
> > > > > >
> > > > > > In terms of preservation, GH wikis act just like any other Git
> > > > repository, with a remote at (for example) git@github.com:
> > > > apache/accumulo.wiki.git
> > > > > > IIRC the pages are just GH flavored markdown. There are at least
> a
> > few
> > > > Apache projects using them.
> > > > > >
> > > > > > However, GH wikis lack some features that I feel are important to
> > > > support collaborative authoring. For example, the ability to comment
> > and
> > > > discuss specific passages in a document is a feature that's present
> in
> > > > Cwiki, but not in GH wikis. I've come appreciate this this in my
> google
> > > > docs and office workflows, so expect that it would be useful for
> > Accumulo
> > > > design discussions too.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kturner@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > > I would like to try a wiki for design documents, I think it
> > would be
> > > > > > > less cumbersome than the website and we can always link from
> the
> > > > > > > website and issues to the wiki. I think its ok to give it a
> try
> > and
> > > > > > > abandon it in the future, if abandoned would just need to
> > properly
> > > > > > > communicate that. The content should be archived in Apache
> > > > > > > infrastructure, so if GH wiki does not do that then we should
> > not use
> > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > >
> > > > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > > > > > >
> > > > > > > > I reverted the change. I didn't think it would be a big deal,
> > but
> > > > if
> > > > > > > > it
> > > > > > > requires discussion, then let's discuss it.
> > > > > > > >
> > > > > > > > I'm looking for a place to host information related to
> internal
> > > > > > > > design
> > > > > > > discussions. I envision these to be living documents that will
> be
> > > > > > > updated over time as the design/implementation progresses and
> > that
> > > > > > > other committers will be able to comment on and edit. I don't
> > feel
> > > > > > > that the website is the correct place for this because:
> > > > > > > >
> > > > > > > > 1. I don't think internal design discussions should go on
> the
> > > > > > > > project
> > > > > > > website.
> > > > > > > > 2. Changes to the design documents could not be seen by
> > others
> > > > > > > > right
> > > > > > > away (IIRC changes to the website are built and available at
> > > > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > > >
> > > > > > > > I looked in the INFRA issues and other projects are using the
> > GH
> > > > > > > > Wiki
> > > > > > > feature and I saw no mention of backing it up or the
> requirement
> > to
> > > > do
> > > > > > > so (maybe they rely on GitHub backing it up?). It does appear
> > that we
> > > > > > > would need an INFRA ticket so that they can modify the GitHub
> > project
> > > > > > > settings to lock the GitHub wiki down so that only committers
> can
> > > > > > > modify it. If GitHub Wiki is not acceptable, then I think
> Apache
> > > > > > > Confluence (
> > > > > > > https://cwiki.apache.org) might be an acceptable alternative.
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > Subject: Re: [accumulo] branch main updated: Enable Github
> > wiki in
> > > > > > > asf.yaml
> > > > > > > >
> > > > > > > > I don't recall a discussion about this change, but I think it
> > goes
> > > > > > > against previous efforts to make the website the one canonical
> > > > > > > location for our documentation. I don't even think infra is
> > backing
> > > > up
> > > > > > > wiki repos, so there wouldn't even be a record of the wiki
> > contents
> > > > in
> > > > > > > ASF spaces (vs. the main repo, which is backed up to GitBox and
> > the
> > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > >
> > > > > > > > In short, I think this should be reverted and we should not
> > use the
> > > > > > > GitHub wiki. If we need to store documents in a version
> > controlled
> > > > > > > way, we can store them on the website, or in our project's SVN
> > dev
> > > > > > > space. The wiki is just another place people would have to
> > follow if
> > > > > > > they want to participate, and I don't think that serves us.
> > > > Therefore,
> > > > > > > I think we shouldn't use it.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > > > >
> > > > > > > > > This is an automated email from the ASF dual-hosted git
> > > > repository.
> > > > > > > > >
> > > > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The following commit(s) were added to refs/heads/main by
> this
> > > > push:
> > > > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml
> > ae8a817e7b is
> > > > > > > > > described below
> > > > > > > > >
> > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > >
> > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > ---
> > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > bc2c943e82..08aa357082
> > > > > > > > > 100644
> > > > > > > > > --- a/.asf.yaml
> > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > - big-data
> > > > > > > > > - hacktoberfest
> > > > > > > > > features:
> > > > > > > > > - wiki: false
> > > > > > > > > + wiki: true
> > > > > > > > > issues: true
> > > > > > > > > projects: true
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
All discussions in GitHub issues go to the notifications list so people can
follow. We don't usually need to recap, but if somebody wanted to, they
could reply to the dev list in response to a message sent to notifications.
The wiki doesn't have issues, discussions, or l etc., and I don't know what
kind of notifications it has to help others follow it. It seems like it'd
be important to ensure there are notifications of activity to the
notifications list for that.
On Wed, Mar 15, 2023, 13:43 Daniel Roberts <dd...@gmail.com> wrote:
> +1 for the GH wiki with major discussions still being fed into, or
> originated on the mailing lists.
>
> As a side question, if there is a lengthy discussion on a GH issue, is it
> standard practice to just recap that in a mailing list message?
> Or is there a more "formal" inclusion process to follow?
>
>
> On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org> wrote:
>
> > I don't think the workflow I proposed about using PRs and discussion on
> > tickets, etc. and the accompanying arguments about keeping things
> > consolidated and accessible to potential contributors not participating
> on
> > GitHub, were really challenged at all. However, since I seem to be the
> only
> > one advocating for using the website, to keep things centralized, as per
> > previous attempts to consolidate documentation, I won't fight the use of
> > GitHub wiki. But I do want to make it clear that we're proceeding in that
> > direction under my objection (-0), and that I'm not convinced this is the
> > best path forward. Hopefully, I will be proven wrong in time.
> >
> > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > can re-evaluate things once the Apache confluence issue is sorted out.
> > >
> > > Agreed.
> > >
> > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> > >
> > > > I just tried (Wed, 3/15) and still received the same error. I asked
> on
> > > > the infra slack channel and they replied that they are still working
> to
> > > > determine what the issue is - signs are pointing to something inside
> of
> > > > confluence, but no progress.
> > > >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > > can re-evaluate things once the Apache confluence issue is sorted
> out.
> > > >
> > > > Ed Coleman
> > > >
> > > > -----Original Message-----
> > > > From: Dave Marion <dm...@gmail.com>
> > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > To: dev@accumulo.apache.org
> > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >
> > > > Looking at the Infra slack channel response, one of the responses in
> > the
> > > > channel said that "it's some sort of db corruption according to
> > > Atlassian".
> > > > Doesn't sound good....
> > > >
> > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com>
> > wrote:
> > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > unresolved
> > > > > and the only comment on the ticket is one that Ed added two days
> ago
> > > > > requesting an ACCUMULO wiki space.
> > > > >
> > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> > > > >
> > > > >> I do not see any comments in the infa slack channel - so no
> updates
> > > > >> for now.
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Dave Marion <dm...@gmail.com>
> > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > >> To: dev@accumulo.apache.org
> > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >>
> > > > >> Right, I was just curious if there was any follow-up as I think Ed
> > > > >> said that it was going to be discussed by the INFRA team
> yesterday.
> > > > >> There is at least one other recent ticket (
> > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> selfserve
> > > > >> had an issue and the INFRA team created the space manually.
> > > > >>
> > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org>
> > > > wrote:
> > > > >>
> > > > >> > You can track that issue at
> > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > >> >
> > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> dmarion18@gmail.com>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > Ed,
> > > > >> > >
> > > > >> > > Any update from INFRA on being able to create confluence
> > pages?
> > > > >> > >
> > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> ctubbsii@apache.org
> > >
> > > > >> wrote:
> > > > >> > >
> > > > >> > > > We've definitely used the website for more than that. We use
> > it
> > > > >> > > > to document things for users, help developers know how to
> > > > >> > > > contribute, store drafts of designs, share user stories via
> > > > >> > > > blogs, do release announcements, and more. There's
> definitely
> > > > >> > > > space on the website to do this kind of thing, if we want
> to.
> > > > >> > > > We've used it that way before. If you only see it as a place
> > > > >> > > > "for user consumption after everything has been finalized",
> > > > >> > > > then you're missing out on the other ways we currently use
> the
> > > > >> > > > site, and the ways we've used it in
> > > > >> the past.
> > > > >> > > >
> > > > >> > > > With the website, most of the collaboration would happen in
> > the
> > > > >> > > > GH issues about proposed designs or changes to designs, just
> > > > >> > > > like we do today with code or other documentation, which
> > > > >> > > > everybody is used to. I agree it's not as good as Google
> Docs
> > > > >> > > > for on-the-fly comments/annotations, but I don't think
> > > > >> > > > Confluence or Wiki are as good as that either, and Google
> Docs
> > > > isn't really an option...
> > > > >> > > > unless you just want to link to it in the mailing list and
> > > > >> > > > stick to Google Docs from your personal Google account,
> until
> > > > >> > > > it's ready for publication, which would also be fine (any
> > > > >> > > > interested persons can simply request write access by
> replying
> > > > >> > > > to the message where
> > > > >> you shared the link)..
> > > > >> > > >
> > > > >> > > > We are a much smaller project than many others, and we have
> > > > >> > > > previously suffered from having stuff too spread out. Even
> if
> > > > >> > > > other projects find a separate space valuable for them, I'm
> > not
> > > > >> > > > sure it's best for the Accumulo project. While I think it's
> > > > >> > > > useful to examine what other projects do, I do think we
> should
> > > > >> > > > be careful to adopt anything just because others find it
> > > > convenient for them.
> > > > >> > > >
> > > > >> > > > Confluence is my second choice, but with a big gap between
> it
> > > > >> > > > and my first choice.
> > > > >> > > >
> > > > >> > > > On a personal note: I hate using Confluence, because I think
> > > > >> > > > the navigation is highly unintuitive, as is the permissions
> > > > >> > > > model, and I don't like the idea of learning yet another
> > > > >> > > > wiki-syntax (though I've read Confluence supports some
> limited
> > > > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I
> also
> > > > >> > > > do not want to set up custom notifications for watching yet
> > > > >> > > > another space. If we use Confluence, I will probably
> > contribute
> > > > >> > > > very infrequently there because of my frustrations with
> having
> > > > >> > > > used it before. However, that would be my choice, and should
> > > > >> > > > not be a reason the project chooses one over another. I'm
> > > > >> > > > sharing my personal opinion only because it is influencing
> my
> > > > >> > > > opinion about the website being more accessible, via our
> > > > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder how
> > > > >> > > > many other potential contributors would feel similarly. It's
> > > > >> > > > hard to know, since it seems like a lot of this is
> subjective,
> > > > >> > > > and is going to come down to a consensus of personal
> > > > >> preferences.
> > > > >> > > >
> > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > >> > > > <dm...@gmail.com>
> > > > >> > wrote:
> > > > >> > > > >
> > > > >> > > > > I don't see the website as an area where we would have
> > > > >> > > > > collaborative discussions about an idea. For example,
> making
> > > > >> > > > > comments and
> > > > >> > suggestions
> > > > >> > > > on
> > > > >> > > > > a document like you can do in Google Docs. I see the
> website
> > > > >> > > > > as a
> > > > >> > place
> > > > >> > > > > where items are documented for user consumption after
> > > > >> > > > > everything has
> > > > >> > been
> > > > >> > > > > finalized. I'm not trying to create a private discussion
> > > > >> > > > > area, I
> > > > >> > think
> > > > >> > > > > anyone can see the wiki (but I think anonymous comments
> are
> > > > >> > > > > disabled
> > > > >> > due
> > > > >> > > > to
> > > > >> > > > > spam issues). I see no issue with putting work-in-progress
> > > > >> > > > > documents
> > > > >> > on a
> > > > >> > > > > wiki and referencing them via emails to the dev list. I
> > think
> > > > >> > > > > this is
> > > > >> > > > done
> > > > >> > > > > in a lot of other projects. Non-committers that don't have
> > > > >> > > > > access to
> > > > >> > the
> > > > >> > > > > wiki and want to make comments, suggestions, and ask
> > > > >> > > > > questions can
> > > > >> > do so
> > > > >> > > > > via the mailing list. I think it's also possible that
> people
> > > > >> > > > > can get confluence accounts (see
> > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > >> > > > > so if a non-committer wanted to participate they could.
> > > > >> > > > >
> > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > >> > > > > <ct...@apache.org>
> > > > >> > wrote:
> > > > >> > > > >
> > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > >> > > > > > <dm...@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > I'm opposed to using the website for the reasons I
> > > > >> > > > > > > specified
> > > > >> > > > earlier, so
> > > > >> > > > > > it
> > > > >> > > > > >
> > > > >> > > > > > Your reasons that I saw were:
> > > > >> > > > > >
> > > > >> > > > > > > 1. I don't think internal design discussions should go
> > on
> > > > >> > > > > > > the
> > > > >> > project
> > > > >> > > > > > website.
> > > > >> > > > > >
> > > > >> > > > > > That doesn't look to me like a reason. That appears to
> > just
> > > > >> > > > > > be
> > > > >> > stating
> > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > >> > > > > >
> > > > >> > > > > > > 2. Changes to the design documents could not be seen
> by
> > > > >> > > > > > > others
> > > > >> > right
> > > > >> > > > > > away (IIRC changes to the website are built and
> available
> > > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > > >> > > > > > intervention is
> > > > >> > > > required
> > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > >> > > > > >
> > > > >> > > > > > What do you mean by "others" here? Do you mean "users",
> as
> > > > >> > > > > > opposed
> > > > >> > to
> > > > >> > > > > > "developers/contributors"? The ASF draws a distinction
> > > > >> > > > > > between "developers/contributors" and "users" as it
> > > > >> > > > > > pertains to official releases. Releases are intended to
> be
> > > > >> > > > > > consumed by users, and pre-release stuff is intended to
> be
> > > > >> > > > > > collaborative, open to all potential
> > > > >> > > > > > developers/contributors. Very very rarely are things
> > > > >> > > > > > reserved exclusively for committers. We don't even have
> a
> > > > >> > > > > > private committers space (the private mailing list is
> > > > >> > > > > > PMC-private, not committer-private). Having a
> distinction
> > > > >> > > > > > between users and
> > > > >> > developers
> > > > >> > > > > > doesn't mean we can't publish things on the website...
> it
> > > > >> > > > > > just
> > > > >> > means
> > > > >> > > > > > that we should be careful about how we do it, which is
> the
> > > > >> > > > > > same
> > > > >> > care
> > > > >> > > > > > we should take regardless of where we put it.
> > Specifically,
> > > > >> > > > > > the
> > > > >> > care
> > > > >> > > > > > we need to take is to avoid marketing pre-release
> content
> > > > >> > > > > > to
> > > > >> users.
> > > > >> > > > > > One way we can exercise this care for content on our
> > > > >> > > > > > website is
> > > > >> > that
> > > > >> > > > > > we can avoid sharing these unpolished designs by simply
> > not
> > > > >> > > > > > linking them on the site, or by placing them in an area
> > > > >> > > > > > that is clearly
> > > > >> > marked
> > > > >> > > > > > as intended for devs. But, we have no similar
> distinction
> > > > >> > > > > > between committers and non-committer devs for which we
> > > > >> > > > > > should avoid sharing pre-release content under
> > development.
> > > > >> > > > > > In fact, it is the
> > > > >> > opposite...
> > > > >> > > > > > we should be developing openly so as to allow room for
> > > > >> > non-committers
> > > > >> > > > > > to become committers through participation in
> development
> > > > >> > activities.
> > > > >> > > > > >
> > > > >> > > > > > As for the staging/publication of the website, that's
> just
> > > > >> > > > > > a
> > > > >> > mechanic
> > > > >> > > > > > for verifying the website isn't broken before we serve
> it.
> > > > >> > > > > > It's
> > > > >> > not a
> > > > >> > > > > > mechanism for keeping things internal vs. shared and
> > > > >> > > > > > doesn't have anything to do with the separation between
> > > > >> > > > > > devs and users. We
> > > > >> > already
> > > > >> > > > > > publish Draft contents to the website, as well as
> > > > >> > developer-specific
> > > > >> > > > > > documentation not intended for users.
> > > > >> > > > > >
> > > > >> > > > > > We've even specifically published work-in-progress
> design
> > > > >> > > > > > documents there, of the same type that seems to be the
> > > > >> > > > > > basis of this conversation (
> > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > >> > I
> > > > >> > > > > > would strongly prefer us to continue to do it this way,
> > > > >> > > > > > rather than create a new space, and have these kinds of
> > > > >> > > > > > things scattered in multiple places.
> > > > >> > > > > >
> > > > >> > > > > > If, on the other hand, you intend to say that these
> should
> > > > >> > > > > > be
> > > > >> > private
> > > > >> > > > > > because they aren't ready for other potential
> > contributors,
> > > > >> > > > > > then I would argue that we're an openly developed
> > project...
> > > > >> > > > > > if something isn't ready to be shared with other
> potential
> > > > >> > > > > > contributors / developers, such that you want to keep it
> > > > >> > > > > > internal to existing committers, then it's not ready to
> be
> > > > >> > > > > > contributed to the project at all... because we don't
> > > > >> > > > > > restrict collaboration to only existing committers. That
> > > > >> > > > > > would prevent others from participating and
> > > > >> > earning
> > > > >> > > > > > the merit to become committers, and that's not something
> > we
> > > > >> > > > > > should
> > > > >> > be
> > > > >> > > > > > doing. Anything that is okay to share with existing
> > > > >> > > > > > committers
> > > > >> > should
> > > > >> > > > > > be okay to share to other potential contributors who
> want
> > > > >> > > > > > to participate, and should be done in a space that
> allows
> > > > >> > > > > > them to do that. The website is a perfect space for
> that,
> > > > >> > > > > > and has everything
> > > > >> > we
> > > > >> > > > > > need. I'm actually not sure about Confluence... I
> suspect
> > > > >> > > > > > non-committers wouldn't be able to participate there
> > > > >> > > > > > because they probably can't get accounts for it.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > > looks like we need to
> > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious how
> > much
> > > > >> > > > > > > we
> > > > >> > need to
> > > > >> > > > use
> > > > >> > > > > > > the mailing list during
> > > > >> > > > > > > the design phase. We can announce meeting dates/times
> on
> > > > >> > > > > > > the
> > > > >> > mailing
> > > > >> > > > list
> > > > >> > > > > > > and post links to
> > > > >> > > > > > > meeting notes in Confluence. Ultimately, decisions
> made
> > > > >> > > > > > > by the
> > > > >> > people
> > > > >> > > > > > that
> > > > >> > > > > > > want to be involved
> > > > >> > > > > > > will turn into pull requests against the codebase
> which
> > > > >> > comitters can
> > > > >> > > > > > weigh
> > > > >> > > > > > > in on. When you say,
> > > > >> > > > > > > "... but decisions about those would still need to be
> > > > >> > > > > > > done on the
> > > > >> > > > mailing
> > > > >> > > > > > > list." Are you saying that we need to discuss every
> > > > >> > > > > > > single design decision on the mailing
> > > > >> > list?
> > > > >> > > > > >
> > > > >> > > > > > Yes and no. I am saying that decisions need to happen on
> > > > >> > > > > > the
> > > > >> > mailing
> > > > >> > > > > > list, but I agree with you that this can be satisfied
> > > > >> > > > > > through pull requests. I just wanted to emphasize that
> > > > >> > > > > > regardless of where we do that pre-decision
> collaboration,
> > > > >> > > > > > that collaboration should not be misconstrued as a
> > decision
> > > > >> > > > > > to
> > > > >> accept those ideas into the project.
> > > > >> > The
> > > > >> > > > > > decision occurs during the PR or other activity that
> > > > >> > > > > > interfaces
> > > > >> > with
> > > > >> > > > > > the mailing list, subsequent to the collaboration in the
> > > > >> > design/idea
> > > > >> > > > > > phase.
> > > > >> > > > > >
> > > > >> > > > > > As for the pre-decision collaboration space we're
> > > > >> > > > > > discussing, I
> > > > >> > just
> > > > >> > > > > > want to be careful that we're not creating such a space
> in
> > > > >> > > > > > an exclusionary way that allows only existing committers
> > to
> > > > >> > participate,
> > > > >> > > > > > that excludes other potential contributors. This is
> still
> > > > >> > > > > > an openly-developed project, and we should collaborate
> in
> > a
> > > > >> > > > > > space
> > > > >> > that is
> > > > >> > > > > > not exclusive to existing committers, but open to
> > > > >> > > > > > non-committer contributors and potential contributors as
> > > well.
> > > > >> > > > > > So, while we may
> > > > >> > want
> > > > >> > > > > > to keep a line separating dev activity from user
> > > > >> > > > > > consumption (an important separation that relates to
> > > > >> > > > > > official ASF releases), we
> > > > >> > should
> > > > >> > > > > > not be drawing a line between committer-devs as
> "internal"
> > > > >> > > > > > and contributor-devs as "external". The website, with
> its
> > > > >> > > > > > own issue tracker, the ability to render markdown, do
> > > > >> > > > > > reviews, and collaboratively edit, seems like the ideal
> > > > >> > > > > > place to me. We've used
> > > > >> > it
> > > > >> > > > > > before for the same purpose, and I think we should
> > continue
> > > > >> > > > > > to do
> > > > >> > so.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > >> > > > > > > <ctubbsii@apache.org
> > > > >> > >
> > > > >> > > > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > So, I agree a space would be helpful. Although it's
> > old
> > > > >> > > > > > > > school
> > > > >> > and
> > > > >> > > > > > > > inconvenient, the mailing list is the canonical
> place
> > > > >> > > > > > > > for
> > > > >> > > > discussion.
> > > > >> > > > > > > > We currently use GitHub issues a lot, but that's
> > copied
> > > > >> > > > > > > > to a
> > > > >> > > > mailing
> > > > >> > > > > > > > list (as is our old JIRA space), so if people want
> to
> > > > >> > participate
> > > > >> > > > > > > > without a GitHub account, they can still do that.
> > There
> > > > >> > > > > > > > are
> > > > >> > certain
> > > > >> > > > > > > > options that are perhaps less convenient, such as
> just
> > > > >> > > > > > > > using
> > > > >> > the
> > > > >> > > > > > > > mailing list and our dev SVN space, but still more
> > > > >> > > > > > > > appropriate
> > > > >> > than
> > > > >> > > > > > > > options that would be less ubiquitous for potential
> > > > >> > participants.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > > > >> > > > > > > > storing,
> > > > >> > editing,
> > > > >> > > > and
> > > > >> > > > > > > > collaborating on shared documents, but decisions
> about
> > > > >> > > > > > > > those
> > > > >> > would
> > > > >> > > > > > > > still need to be done on the mailing list. If I
> > > > >> > > > > > > > remember
> > > > >> > > > correctly, we
> > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > >> > > > > > > > maintained, so we abandoned it in
> > > > >> > > > favor
> > > > >> > > > > > > > of using the website for docs. I could be
> > > > >> > > > > > > > mis-remembering, but
> > > > >> > I
> > > > >> > > > think
> > > > >> > > > > > > > this is the case. It might explain why you can't
> > create
> > > > >> > > > > > > > a
> > > > >> > > > Confluence
> > > > >> > > > > > > > space.
> > > > >> > > > > > > >
> > > > >> > > > > > > > My preference would be to just use the website. I
> > think
> > > > >> > > > > > > > it's
> > > > >> > fine
> > > > >> > > > to
> > > > >> > > > > > > > have a dev / design area of the website, and we can
> > > > >> > > > > > > > discuss on
> > > > >> > > > GitHub
> > > > >> > > > > > > > issues for the accumulo-website repo. That is a bit
> > > > >> > > > > > > > less
> > > > >> > convenient
> > > > >> > > > > > > > than Confluence if it's used heavily, but it's more
> > > > >> > > > > > > > convenient
> > > > >> > in
> > > > >> > > > the
> > > > >> > > > > > > > sense that it's more accessible and fits more in
> line
> > > > >> > > > > > > > with our
> > > > >> > > > current
> > > > >> > > > > > > > mode of operation. Plus, when a document is final,
> > it's
> > > > >> > > > > > > > easy to
> > > > >> > > > link
> > > > >> > > > > > > > to from our documentation, without making users jump
> > to
> > > > >> > > > > > > > another service to view docs.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I would be opposed to using GitHub wiki or a new git
> > > repo.
> > > > >> > > > > > > > We
> > > > >> > have
> > > > >> > > > > > > > enough repos. Although it seems like they are free,
> > > > >> > > > > > > > there is
> > > > >> > still
> > > > >> > > > a
> > > > >> > > > > > > > lot of boilerplate work to maintain them, from
> > managing
> > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> > > > >> > .asf.yaml, to
> > > > >> > > > > > > > README, to keeping copyright dates updated in the
> > > > >> > > > > > > > NOTICE file,
> > > > >> > and
> > > > >> > > > > > > > more.
> > > > >> > > > > > > >
> > > > >> > > > > > > > In summary, my preference:
> > > > >> > > > > > > >
> > > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
> > > > >> > > > > > > > issues and
> > > > >> > > > mailing
> > > > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss on
> > > > >> > > > > > > > mailing list (prefer over other
> > > > >> > options,
> > > > >> > > > but
> > > > >> > > > > > > > not a fan)
> > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
> > > > >> > > > > > > > prefer not
> > > > >> > to use
> > > > >> > > > > > this
> > > > >> > > > > > > > option)
> > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing
> > > > >> > > > > > > > list
> > > > >> > (strongly
> > > > >> > > > > > > > prefer not to use this option)
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > >> > edcoleman@apache.org>
> > > > >> > > > > > wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Currently, asf cannot create new wiki's because
> of a
> > > > >> > Confluence
> > > > >> > > > > > issue (
> > > > >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291)
> I
> > > > >> > > > > > > > chatted
> > > > >> > with
> > > > >> > > > > > infra
> > > > >> > > > > > > > and in response they created that issue.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > To expand on this discussion, I would like to toss
> > > > >> > > > > > > > > out
> > > > >> > another
> > > > >> > > > > > > > alternative to discuss / explore. What if we used a
> > > > >> > > > > > > > separate
> > > > >> > > > GitHub
> > > > >> > > > > > > > project, something like Accumulo-Design, just like
> > > > >> > accumulo-proxy
> > > > >> > > > and
> > > > >> > > > > > > > accumulo-examples. As a separate project, it would
> be
> > > > >> > available
> > > > >> > > > for
> > > > >> > > > > > > > collaboration for the community, but remain separate
> > > > >> > > > > > > > from main
> > > > >> > > > project
> > > > >> > > > > > and
> > > > >> > > > > > > > the website to keep current code / documentation /
> > > > >> > > > > > > > design
> > > > >> > clearly
> > > > >> > > > > > separate
> > > > >> > > > > > > > from speculative design discussions. As a project:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > - document history would be preserved with git
> > commit
> > > > >> > history.
> > > > >> > > > > > > > > - document collaboration could be done with normal
> > PR
> > > > >> > > > submissions /
> > > > >> > > > > > > > reviews.
> > > > >> > > > > > > > > - issues could be used to discuss design aspects,
> > > > >> > > > > > > > > capturing
> > > > >> > the
> > > > >> > > > > > comment
> > > > >> > > > > > > > history.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > The biggest downside is that it would be yet
> another
> > > > >> > > > > > > > > project
> > > > >> > to
> > > > >> > > > > > follow /
> > > > >> > > > > > > > track.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > For me, I think the issue is that we need a
> public,
> > > > >> > collaborative
> > > > >> > > > > > space
> > > > >> > > > > > > > to hold design discussions. Neither the main project
> > or
> > > > >> > > > > > > > the
> > > > >> > > > web-site
> > > > >> > > > > > seem
> > > > >> > > > > > > > quite appropriate and Confluence seems to lack the
> > > > >> > collaboration
> > > > >> > > > that
> > > > >> > > > > > can
> > > > >> > > > > > > > be achieved with github.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > We need a space to capture the redesign and
> whatever
> > > > >> > > > > > > > > we
> > > > >> > select
> > > > >> > > > can be
> > > > >> > > > > > > > made to work - I'm just wondering what provides the
> > > > >> > > > > > > > easiest
> > > > >> > forum
> > > > >> > > > to
> > > > >> > > > > > build
> > > > >> > > > > > > > a collaborative space for the Accumulo community.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Ed Coleman
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net
> wrote:
> > > > >> > > > > > > > > > Circling back on this issue - I agree that
> > comments
> > > > >> > > > > > > > > > and
> > > > >> > such
> > > > >> > > > make
> > > > >> > > > > > > > sense for internal design documents. I'm going to
> > > > >> > > > > > > > create an
> > > > >> > INFRA
> > > > >> > > > > > ticket
> > > > >> > > > > > > > for a cwiki space for Accumulo unless there are any
> > > > >> objections.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > -----Original Message-----
> > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> > > asf.yaml?
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > As mentioned, wikis can provide a streamlined
> > > > >> > > > > > > > > > collaborative
> > > > >> > > > editing
> > > > >> > > > > > > > workflow that's less labor intensive than updating a
> > > > >> website.
> > > > >> > They
> > > > >> > > > can
> > > > >> > > > > > > > promote collaboration by providing specific tooling
> to
> > > > >> > > > > > > > support
> > > > >> > > > > > comments,
> > > > >> > > > > > > > revisions and iteration.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > In terms of preservation, GH wikis act just like
> > > > >> > > > > > > > > > any other
> > > > >> > Git
> > > > >> > > > > > > > repository, with a remote at (for example)
> > > git@github.com
> > > > :
> > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > >> > > > > > > > > > IIRC the pages are just GH flavored markdown.
> > There
> > > > >> > > > > > > > > > are at
> > > > >> > > > least a
> > > > >> > > > > > few
> > > > >> > > > > > > > Apache projects using them.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > However, GH wikis lack some features that I feel
> > > > >> > > > > > > > > > are
> > > > >> > important
> > > > >> > > > to
> > > > >> > > > > > > > support collaborative authoring. For example, the
> > > > >> > > > > > > > ability to
> > > > >> > > > comment
> > > > >> > > > > > and
> > > > >> > > > > > > > discuss specific passages in a document is a feature
> > > > >> > > > > > > > that's
> > > > >> > > > present in
> > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate
> this
> > > > >> > > > > > > > this in
> > > > >> > my
> > > > >> > > > google
> > > > >> > > > > > > > docs and office workflows, so expect that it would
> be
> > > > >> > > > > > > > useful
> > > > >> > for
> > > > >> > > > > > Accumulo
> > > > >> > > > > > > > design discussions too.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > > >> > > > kturner@apache.org>
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > > I would like to try a wiki for design
> documents,
> > > > >> > > > > > > > > > > I think
> > > > >> > it
> > > > >> > > > > > would be
> > > > >> > > > > > > > > > > less cumbersome than the website and we can
> > > > >> > > > > > > > > > > always link
> > > > >> > from
> > > > >> > > > the
> > > > >> > > > > > > > > > > website and issues to the wiki. I think its
> ok
> > > > >> > > > > > > > > > > to give
> > > > >> > it a
> > > > >> > > > try
> > > > >> > > > > > and
> > > > >> > > > > > > > > > > abandon it in the future, if abandoned would
> > just
> > > > >> > > > > > > > > > > need to
> > > > >> > > > > > properly
> > > > >> > > > > > > > > > > communicate that. The content should be
> > archived
> > > > >> > > > > > > > > > > in
> > > > >> > Apache
> > > > >> > > > > > > > > > > infrastructure, so if GH wiki does not do that
> > > > >> > > > > > > > > > > then we
> > > > >> > should
> > > > >> > > > > > not use
> > > > >> > > > > > > > > > > it. If GH wiki is not an option then could
> try
> > > > cwiki.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > >> > > > wrote:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I reverted the change. I didn't think it
> would
> > > > >> > > > > > > > > > > > be a big
> > > > >> > > > deal,
> > > > >> > > > > > but
> > > > >> > > > > > > > if
> > > > >> > > > > > > > > > > > it
> > > > >> > > > > > > > > > > requires discussion, then let's discuss it.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I'm looking for a place to host information
> > > > >> > > > > > > > > > > > related to
> > > > >> > > > internal
> > > > >> > > > > > > > > > > > design
> > > > >> > > > > > > > > > > discussions. I envision these to be living
> > > > >> > > > > > > > > > > documents that
> > > > >> > > > will be
> > > > >> > > > > > > > > > > updated over time as the design/implementation
> > > > >> > progresses and
> > > > >> > > > > > that
> > > > >> > > > > > > > > > > other committers will be able to comment on
> and
> > > > >> > > > > > > > > > > edit. I
> > > > >> > don't
> > > > >> > > > > > feel
> > > > >> > > > > > > > > > > that the website is the correct place for this
> > > > >> because:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > 1. I don't think internal design
> discussions
> > > > >> > > > > > > > > > > > should
> > > > >> > go
> > > > >> > > > on the
> > > > >> > > > > > > > > > > > project
> > > > >> > > > > > > > > > > website.
> > > > >> > > > > > > > > > > > 2. Changes to the design documents could
> not
> > > > >> > > > > > > > > > > > be seen
> > > > >> > by
> > > > >> > > > > > others
> > > > >> > > > > > > > > > > > right
> > > > >> > > > > > > > > > > away (IIRC changes to the website are built
> and
> > > > >> > available at
> > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but
> human
> > > > >> > intervention
> > > > >> > > > is
> > > > >> > > > > > > > > > > required to publish it at
> > > > >> https://accumulo.apache.org/).
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I looked in the INFRA issues and other
> > projects
> > > > >> > > > > > > > > > > > are
> > > > >> > using
> > > > >> > > > the
> > > > >> > > > > > GH
> > > > >> > > > > > > > > > > > Wiki
> > > > >> > > > > > > > > > > feature and I saw no mention of backing it up
> or
> > > > >> > > > > > > > > > > the
> > > > >> > > > requirement
> > > > >> > > > > > to
> > > > >> > > > > > > > do
> > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing it up?).
> > It
> > > > >> > > > > > > > > > > does
> > > > >> > appear
> > > > >> > > > > > that we
> > > > >> > > > > > > > > > > would need an INFRA ticket so that they can
> > > > >> > > > > > > > > > > modify the
> > > > >> > GitHub
> > > > >> > > > > > project
> > > > >> > > > > > > > > > > settings to lock the GitHub wiki down so that
> > > > >> > > > > > > > > > > only
> > > > >> > > > committers can
> > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable,
> > then
> > > > >> > > > > > > > > > > I think
> > > > >> > > > Apache
> > > > >> > > > > > > > > > > Confluence (
> > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > acceptable
> > > > >> > > > alternative.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > -----Original Message-----
> > > > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > >> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> > > > >> > > > > > > > > > > > Enable
> > > > >> > Github
> > > > >> > > > > > wiki in
> > > > >> > > > > > > > > > > asf.yaml
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I don't recall a discussion about this
> change,
> > > > >> > > > > > > > > > > > but I
> > > > >> > think
> > > > >> > > > it
> > > > >> > > > > > goes
> > > > >> > > > > > > > > > > against previous efforts to make the website
> the
> > > > >> > > > > > > > > > > one
> > > > >> > > > canonical
> > > > >> > > > > > > > > > > location for our documentation. I don't even
> > > > >> > > > > > > > > > > think infra
> > > > >> > is
> > > > >> > > > > > backing
> > > > >> > > > > > > > up
> > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a record
> > of
> > > > >> > > > > > > > > > > the
> > > > >> > wiki
> > > > >> > > > > > contents
> > > > >> > > > > > > > in
> > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed
> > up
> > > > >> > > > > > > > > > > to
> > > > >> > GitBox
> > > > >> > > > and
> > > > >> > > > > > the
> > > > >> > > > > > > > > > > issue tracker, which CCs the notifications
> > list).
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > In short, I think this should be reverted
> and
> > > > >> > > > > > > > > > > > we
> > > > >> > should not
> > > > >> > > > > > use the
> > > > >> > > > > > > > > > > GitHub wiki. If we need to store documents in
> a
> > > > >> > > > > > > > > > > version
> > > > >> > > > > > controlled
> > > > >> > > > > > > > > > > way, we can store them on the website, or in
> our
> > > > >> > project's
> > > > >> > > > SVN
> > > > >> > > > > > dev
> > > > >> > > > > > > > > > > space. The wiki is just another place people
> > > > >> > > > > > > > > > > would have
> > > > >> > to
> > > > >> > > > > > follow if
> > > > >> > > > > > > > > > > they want to participate, and I don't think
> that
> > > > >> > > > > > > > > > > serves
> > > > >> > us.
> > > > >> > > > > > > > Therefore,
> > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > >> > wrote:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > This is an automated email from the ASF
> > > > >> > > > > > > > > > > > > dual-hosted
> > > > >> > git
> > > > >> > > > > > > > repository.
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
> > > > >> > > > > > > > > > > > > repository
> > > > >> > > > > > > > > > > > >
> > https://gitbox.apache.org/repos/asf/accumulo.
> > > > >> > > > > > > > > > > > > git
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > The following commit(s) were added to
> > > > >> > refs/heads/main by
> > > > >> > > > this
> > > > >> > > > > > > > push:
> > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> > > > >> > > > > > > > > > > > > asf.yaml
> > > > >> > > > > > ae8a817e7b is
> > > > >> > > > > > > > > > > > > described below
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > commit
> > > > >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > >> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > >> > > > > > > > > > > > > ---
> > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > >> > > > > > > > > > > > > deletion(-)
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > >> > > > > > bc2c943e82..08aa357082
> > > > >> > > > > > > > > > > > > 100644
> > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > >> > > > > > > > > > > > > - big-data
> > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > >> > > > > > > > > > > > > features:
> > > > >> > > > > > > > > > > > > - wiki: false
> > > > >> > > > > > > > > > > > > + wiki: true
> > > > >> > > > > > > > > > > > > issues: true
> > > > >> > > > > > > > > > > > > projects: true
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > >
> > > > >> > > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
RE: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by dev1 <de...@etcoleman.com>.
One thing to keep in mind is that we should keep the mailing list in mind. Not sure how we integrate two streams of notifications. But, leveraging the mailing list will make sure that the community at large can follow and participate.
Ed Coleman
-----Original Message-----
From: Christopher <ct...@apache.org>
Sent: Wednesday, March 15, 2023 2:16 PM
To: accumulo-dev <de...@accumulo.apache.org>
Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
It seems like there's a majority consensus of those engaged. No need for a vote, but I think the question about notifications should be addressed first.
On Wed, Mar 15, 2023, 13:47 Christopher Shannon < christopher.l.shannon@gmail.com> wrote:
> I'm +1 to using some kind of wiki so if we can't use Confluence then
> GH sounds fine to me. Do we need to take a formal vote for using the
> Github wiki or is there enough consensus already?
>
> On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com> wrote:
>
> > +1 for the GH wiki with major discussions still being fed into, or
> > originated on the mailing lists.
> >
> > As a side question, if there is a lengthy discussion on a GH issue,
> > is it standard practice to just recap that in a mailing list message?
> > Or is there a more "formal" inclusion process to follow?
> >
> >
> > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org> wrote:
> >
> > > I don't think the workflow I proposed about using PRs and
> > > discussion on tickets, etc. and the accompanying arguments about
> > > keeping things consolidated and accessible to potential
> > > contributors not participating
> > on
> > > GitHub, were really challenged at all. However, since I seem to be
> > > the
> > only
> > > one advocating for using the website, to keep things centralized,
> > > as
> per
> > > previous attempts to consolidate documentation, I won't fight the
> > > use
> of
> > > GitHub wiki. But I do want to make it clear that we're proceeding
> > > in
> that
> > > direction under my objection (-0), and that I'm not convinced this
> > > is
> the
> > > best path forward. Hopefully, I will be proven wrong in time.
> > >
> > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> > >
> > > > > At this point, I think we should move forward with a GH wiki
> > > > > and
> then
> > > we
> > > > can re-evaluate things once the Apache confluence issue is
> > > > sorted
> out.
> > > >
> > > > Agreed.
> > > >
> > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> > > >
> > > > > I just tried (Wed, 3/15) and still received the same error. I
> asked
> > on
> > > > > the infra slack channel and they replied that they are still
> working
> > to
> > > > > determine what the issue is - signs are pointing to something
> inside
> > of
> > > > > confluence, but no progress.
> > > > >
> > > > > At this point, I think we should move forward with a GH wiki
> > > > > and
> then
> > > we
> > > > > can re-evaluate things once the Apache confluence issue is
> > > > > sorted
> > out.
> > > > >
> > > > > Ed Coleman
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dave Marion <dm...@gmail.com>
> > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > To: dev@accumulo.apache.org
> > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >
> > > > > Looking at the Infra slack channel response, one of the
> > > > > responses
> in
> > > the
> > > > > channel said that "it's some sort of db corruption according
> > > > > to
> > > > Atlassian".
> > > > > Doesn't sound good....
> > > > >
> > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion
> > > > > <dm...@gmail.com>
> > > wrote:
> > > > >
> > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > unresolved
> > > > > > and the only comment on the ticket is one that Ed added two
> > > > > > days
> > ago
> > > > > > requesting an ACCUMULO wiki space.
> > > > > >
> > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> > > > > >
> > > > > >> I do not see any comments in the infa slack channel - so no
> > updates
> > > > > >> for now.
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > >> To: dev@accumulo.apache.org
> > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > >>
> > > > > >> Right, I was just curious if there was any follow-up as I
> > > > > >> think
> Ed
> > > > > >> said that it was going to be discussed by the INFRA team
> > yesterday.
> > > > > >> There is at least one other recent ticket (
> > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > selfserve
> > > > > >> had an issue and the INFRA team created the space manually.
> > > > > >>
> > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> ctubbsii@apache.org>
> > > > > wrote:
> > > > > >>
> > > > > >> > You can track that issue at
> > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > >> >
> > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > dmarion18@gmail.com>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > Ed,
> > > > > >> > >
> > > > > >> > > Any update from INFRA on being able to create
> > > > > >> > > confluence
> > > pages?
> > > > > >> > >
> > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > ctubbsii@apache.org
> > > >
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > > We've definitely used the website for more than that.
> > > > > >> > > > We
> use
> > > it
> > > > > >> > > > to document things for users, help developers know
> > > > > >> > > > how to contribute, store drafts of designs, share
> > > > > >> > > > user stories
> via
> > > > > >> > > > blogs, do release announcements, and more. There's
> > definitely
> > > > > >> > > > space on the website to do this kind of thing, if we
> > > > > >> > > > want
> > to.
> > > > > >> > > > We've used it that way before. If you only see it as
> > > > > >> > > > a
> place
> > > > > >> > > > "for user consumption after everything has been
> finalized",
> > > > > >> > > > then you're missing out on the other ways we
> > > > > >> > > > currently use
> > the
> > > > > >> > > > site, and the ways we've used it in
> > > > > >> the past.
> > > > > >> > > >
> > > > > >> > > > With the website, most of the collaboration would
> > > > > >> > > > happen
> in
> > > the
> > > > > >> > > > GH issues about proposed designs or changes to
> > > > > >> > > > designs,
> just
> > > > > >> > > > like we do today with code or other documentation,
> > > > > >> > > > which everybody is used to. I agree it's not as good
> > > > > >> > > > as Google
> > Docs
> > > > > >> > > > for on-the-fly comments/annotations, but I don't
> > > > > >> > > > think Confluence or Wiki are as good as that either,
> > > > > >> > > > and Google
> > Docs
> > > > > isn't really an option...
> > > > > >> > > > unless you just want to link to it in the mailing
> > > > > >> > > > list and stick to Google Docs from your personal
> > > > > >> > > > Google account,
> > until
> > > > > >> > > > it's ready for publication, which would also be fine
> > > > > >> > > > (any interested persons can simply request write
> > > > > >> > > > access by
> > replying
> > > > > >> > > > to the message where
> > > > > >> you shared the link)..
> > > > > >> > > >
> > > > > >> > > > We are a much smaller project than many others, and
> > > > > >> > > > we
> have
> > > > > >> > > > previously suffered from having stuff too spread out.
> > > > > >> > > > Even
> > if
> > > > > >> > > > other projects find a separate space valuable for
> > > > > >> > > > them,
> I'm
> > > not
> > > > > >> > > > sure it's best for the Accumulo project. While I
> > > > > >> > > > think
> it's
> > > > > >> > > > useful to examine what other projects do, I do think
> > > > > >> > > > we
> > should
> > > > > >> > > > be careful to adopt anything just because others find
> > > > > >> > > > it
> > > > > convenient for them.
> > > > > >> > > >
> > > > > >> > > > Confluence is my second choice, but with a big gap
> > > > > >> > > > between
> > it
> > > > > >> > > > and my first choice.
> > > > > >> > > >
> > > > > >> > > > On a personal note: I hate using Confluence, because
> > > > > >> > > > I
> think
> > > > > >> > > > the navigation is highly unintuitive, as is the
> permissions
> > > > > >> > > > model, and I don't like the idea of learning yet
> > > > > >> > > > another wiki-syntax (though I've read Confluence
> > > > > >> > > > supports some
> > limited
> > > > > >> > > > Markdown, but probably not the same as
> > > > > >> > > > GitHub/Jekyll). I
> > also
> > > > > >> > > > do not want to set up custom notifications for
> > > > > >> > > > watching
> yet
> > > > > >> > > > another space. If we use Confluence, I will probably
> > > contribute
> > > > > >> > > > very infrequently there because of my frustrations
> > > > > >> > > > with
> > having
> > > > > >> > > > used it before. However, that would be my choice, and
> should
> > > > > >> > > > not be a reason the project chooses one over another.
> > > > > >> > > > I'm sharing my personal opinion only because it is
> > > > > >> > > > influencing
> > my
> > > > > >> > > > opinion about the website being more accessible, via
> > > > > >> > > > our current GitHub PR/issue/Markdown workflows, and I
> > > > > >> > > > wonder
> how
> > > > > >> > > > many other potential contributors would feel similarly.
> It's
> > > > > >> > > > hard to know, since it seems like a lot of this is
> > subjective,
> > > > > >> > > > and is going to come down to a consensus of personal
> > > > > >> preferences.
> > > > > >> > > >
> > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > >> > > > <dm...@gmail.com>
> > > > > >> > wrote:
> > > > > >> > > > >
> > > > > >> > > > > I don't see the website as an area where we would
> > > > > >> > > > > have collaborative discussions about an idea. For
> > > > > >> > > > > example,
> > making
> > > > > >> > > > > comments and
> > > > > >> > suggestions
> > > > > >> > > > on
> > > > > >> > > > > a document like you can do in Google Docs. I see
> > > > > >> > > > > the
> > website
> > > > > >> > > > > as a
> > > > > >> > place
> > > > > >> > > > > where items are documented for user consumption
> > > > > >> > > > > after everything has
> > > > > >> > been
> > > > > >> > > > > finalized. I'm not trying to create a private
> > > > > >> > > > > discussion area, I
> > > > > >> > think
> > > > > >> > > > > anyone can see the wiki (but I think anonymous
> > > > > >> > > > > comments
> > are
> > > > > >> > > > > disabled
> > > > > >> > due
> > > > > >> > > > to
> > > > > >> > > > > spam issues). I see no issue with putting
> work-in-progress
> > > > > >> > > > > documents
> > > > > >> > on a
> > > > > >> > > > > wiki and referencing them via emails to the dev
> > > > > >> > > > > list. I
> > > think
> > > > > >> > > > > this is
> > > > > >> > > > done
> > > > > >> > > > > in a lot of other projects. Non-committers that
> > > > > >> > > > > don't
> have
> > > > > >> > > > > access to
> > > > > >> > the
> > > > > >> > > > > wiki and want to make comments, suggestions, and
> > > > > >> > > > > ask questions can
> > > > > >> > do so
> > > > > >> > > > > via the mailing list. I think it's also possible
> > > > > >> > > > > that
> > people
> > > > > >> > > > > can get confluence accounts (see
> > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > >> > > > > so if a non-committer wanted to participate they could.
> > > > > >> > > > >
> > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > >> > > > > <ct...@apache.org>
> > > > > >> > wrote:
> > > > > >> > > > >
> > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > >> > > > > > <dm...@gmail.com>
> > > > > >> > > > wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > > I'm opposed to using the website for the
> > > > > >> > > > > > > reasons I specified
> > > > > >> > > > earlier, so
> > > > > >> > > > > > it
> > > > > >> > > > > >
> > > > > >> > > > > > Your reasons that I saw were:
> > > > > >> > > > > >
> > > > > >> > > > > > > 1. I don't think internal design discussions
> > > > > >> > > > > > > should
> go
> > > on
> > > > > >> > > > > > > the
> > > > > >> > project
> > > > > >> > > > > > website.
> > > > > >> > > > > >
> > > > > >> > > > > > That doesn't look to me like a reason. That
> > > > > >> > > > > > appears to
> > > just
> > > > > >> > > > > > be
> > > > > >> > stating
> > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > >> > > > > >
> > > > > >> > > > > > > 2. Changes to the design documents could not be
> > > > > >> > > > > > > seen
> > by
> > > > > >> > > > > > > others
> > > > > >> > right
> > > > > >> > > > > > away (IIRC changes to the website are built and
> > available
> > > > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > > > >> > > > > > intervention is
> > > > > >> > > > required
> > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > >> > > > > >
> > > > > >> > > > > > What do you mean by "others" here? Do you mean
> "users",
> > as
> > > > > >> > > > > > opposed
> > > > > >> > to
> > > > > >> > > > > > "developers/contributors"? The ASF draws a
> > > > > >> > > > > > distinction between "developers/contributors" and
> > > > > >> > > > > > "users" as it pertains to official releases.
> > > > > >> > > > > > Releases are intended
> to
> > be
> > > > > >> > > > > > consumed by users, and pre-release stuff is
> > > > > >> > > > > > intended
> to
> > be
> > > > > >> > > > > > collaborative, open to all potential
> > > > > >> > > > > > developers/contributors. Very very rarely are
> > > > > >> > > > > > things reserved exclusively for committers. We
> > > > > >> > > > > > don't even
> have
> > a
> > > > > >> > > > > > private committers space (the private mailing
> > > > > >> > > > > > list is PMC-private, not committer-private).
> > > > > >> > > > > > Having a
> > distinction
> > > > > >> > > > > > between users and
> > > > > >> > developers
> > > > > >> > > > > > doesn't mean we can't publish things on the website...
> > it
> > > > > >> > > > > > just
> > > > > >> > means
> > > > > >> > > > > > that we should be careful about how we do it,
> > > > > >> > > > > > which is
> > the
> > > > > >> > > > > > same
> > > > > >> > care
> > > > > >> > > > > > we should take regardless of where we put it.
> > > Specifically,
> > > > > >> > > > > > the
> > > > > >> > care
> > > > > >> > > > > > we need to take is to avoid marketing pre-release
> > content
> > > > > >> > > > > > to
> > > > > >> users.
> > > > > >> > > > > > One way we can exercise this care for content on
> > > > > >> > > > > > our website is
> > > > > >> > that
> > > > > >> > > > > > we can avoid sharing these unpolished designs by
> simply
> > > not
> > > > > >> > > > > > linking them on the site, or by placing them in
> > > > > >> > > > > > an
> area
> > > > > >> > > > > > that is clearly
> > > > > >> > marked
> > > > > >> > > > > > as intended for devs. But, we have no similar
> > distinction
> > > > > >> > > > > > between committers and non-committer devs for
> > > > > >> > > > > > which we should avoid sharing pre-release content
> > > > > >> > > > > > under
> > > development.
> > > > > >> > > > > > In fact, it is the
> > > > > >> > opposite...
> > > > > >> > > > > > we should be developing openly so as to allow
> > > > > >> > > > > > room for
> > > > > >> > non-committers
> > > > > >> > > > > > to become committers through participation in
> > development
> > > > > >> > activities.
> > > > > >> > > > > >
> > > > > >> > > > > > As for the staging/publication of the website,
> > > > > >> > > > > > that's
> > just
> > > > > >> > > > > > a
> > > > > >> > mechanic
> > > > > >> > > > > > for verifying the website isn't broken before we
> > > > > >> > > > > > serve
> > it.
> > > > > >> > > > > > It's
> > > > > >> > not a
> > > > > >> > > > > > mechanism for keeping things internal vs. shared
> > > > > >> > > > > > and doesn't have anything to do with the
> > > > > >> > > > > > separation
> between
> > > > > >> > > > > > devs and users. We
> > > > > >> > already
> > > > > >> > > > > > publish Draft contents to the website, as well as
> > > > > >> > developer-specific
> > > > > >> > > > > > documentation not intended for users.
> > > > > >> > > > > >
> > > > > >> > > > > > We've even specifically published
> > > > > >> > > > > > work-in-progress
> > design
> > > > > >> > > > > > documents there, of the same type that seems to
> > > > > >> > > > > > be the basis of this conversation (
> > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > >> > I
> > > > > >> > > > > > would strongly prefer us to continue to do it
> > > > > >> > > > > > this
> way,
> > > > > >> > > > > > rather than create a new space, and have these
> > > > > >> > > > > > kinds
> of
> > > > > >> > > > > > things scattered in multiple places.
> > > > > >> > > > > >
> > > > > >> > > > > > If, on the other hand, you intend to say that
> > > > > >> > > > > > these
> > should
> > > > > >> > > > > > be
> > > > > >> > private
> > > > > >> > > > > > because they aren't ready for other potential
> > > contributors,
> > > > > >> > > > > > then I would argue that we're an openly developed
> > > project...
> > > > > >> > > > > > if something isn't ready to be shared with other
> > potential
> > > > > >> > > > > > contributors / developers, such that you want to
> > > > > >> > > > > > keep
> it
> > > > > >> > > > > > internal to existing committers, then it's not
> > > > > >> > > > > > ready
> to
> > be
> > > > > >> > > > > > contributed to the project at all... because we
> > > > > >> > > > > > don't restrict collaboration to only existing committers.
> That
> > > > > >> > > > > > would prevent others from participating and
> > > > > >> > earning
> > > > > >> > > > > > the merit to become committers, and that's not
> something
> > > we
> > > > > >> > > > > > should
> > > > > >> > be
> > > > > >> > > > > > doing. Anything that is okay to share with
> > > > > >> > > > > > existing committers
> > > > > >> > should
> > > > > >> > > > > > be okay to share to other potential contributors
> > > > > >> > > > > > who
> > want
> > > > > >> > > > > > to participate, and should be done in a space
> > > > > >> > > > > > that
> > allows
> > > > > >> > > > > > them to do that. The website is a perfect space
> > > > > >> > > > > > for
> > that,
> > > > > >> > > > > > and has everything
> > > > > >> > we
> > > > > >> > > > > > need. I'm actually not sure about Confluence... I
> > suspect
> > > > > >> > > > > > non-committers wouldn't be able to participate
> > > > > >> > > > > > there because they probably can't get accounts for it.
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > > looks like we need to wait for INFRA to fix
> > > > > >> > > > > > > Confluence. I'd be curious how
> > > much
> > > > > >> > > > > > > we
> > > > > >> > need to
> > > > > >> > > > use
> > > > > >> > > > > > > the mailing list during the design phase. We
> > > > > >> > > > > > > can announce meeting
> dates/times
> > on
> > > > > >> > > > > > > the
> > > > > >> > mailing
> > > > > >> > > > list
> > > > > >> > > > > > > and post links to meeting notes in Confluence.
> > > > > >> > > > > > > Ultimately, decisions
> > made
> > > > > >> > > > > > > by the
> > > > > >> > people
> > > > > >> > > > > > that
> > > > > >> > > > > > > want to be involved will turn into pull
> > > > > >> > > > > > > requests against the codebase
> > which
> > > > > >> > comitters can
> > > > > >> > > > > > weigh
> > > > > >> > > > > > > in on. When you say, "... but decisions about
> > > > > >> > > > > > > those would still need to
> be
> > > > > >> > > > > > > done on the
> > > > > >> > > > mailing
> > > > > >> > > > > > > list." Are you saying that we need to discuss
> > > > > >> > > > > > > every single design decision on the mailing
> > > > > >> > list?
> > > > > >> > > > > >
> > > > > >> > > > > > Yes and no. I am saying that decisions need to
> > > > > >> > > > > > happen
> on
> > > > > >> > > > > > the
> > > > > >> > mailing
> > > > > >> > > > > > list, but I agree with you that this can be
> > > > > >> > > > > > satisfied through pull requests. I just wanted to
> > > > > >> > > > > > emphasize that regardless of where we do that
> > > > > >> > > > > > pre-decision
> > collaboration,
> > > > > >> > > > > > that collaboration should not be misconstrued as
> > > > > >> > > > > > a
> > > decision
> > > > > >> > > > > > to
> > > > > >> accept those ideas into the project.
> > > > > >> > The
> > > > > >> > > > > > decision occurs during the PR or other activity
> > > > > >> > > > > > that interfaces
> > > > > >> > with
> > > > > >> > > > > > the mailing list, subsequent to the collaboration
> > > > > >> > > > > > in
> the
> > > > > >> > design/idea
> > > > > >> > > > > > phase.
> > > > > >> > > > > >
> > > > > >> > > > > > As for the pre-decision collaboration space we're
> > > > > >> > > > > > discussing, I
> > > > > >> > just
> > > > > >> > > > > > want to be careful that we're not creating such a
> space
> > in
> > > > > >> > > > > > an exclusionary way that allows only existing
> committers
> > > to
> > > > > >> > participate,
> > > > > >> > > > > > that excludes other potential contributors. This
> > > > > >> > > > > > is
> > still
> > > > > >> > > > > > an openly-developed project, and we should
> > > > > >> > > > > > collaborate
> > in
> > > a
> > > > > >> > > > > > space
> > > > > >> > that is
> > > > > >> > > > > > not exclusive to existing committers, but open to
> > > > > >> > > > > > non-committer contributors and potential
> > > > > >> > > > > > contributors
> as
> > > > well.
> > > > > >> > > > > > So, while we may
> > > > > >> > want
> > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > >> > > > > > consumption (an important separation that relates
> > > > > >> > > > > > to official ASF releases), we
> > > > > >> > should
> > > > > >> > > > > > not be drawing a line between committer-devs as
> > "internal"
> > > > > >> > > > > > and contributor-devs as "external". The website,
> > > > > >> > > > > > with
> > its
> > > > > >> > > > > > own issue tracker, the ability to render
> > > > > >> > > > > > markdown, do reviews, and collaboratively edit,
> > > > > >> > > > > > seems like the
> ideal
> > > > > >> > > > > > place to me. We've used
> > > > > >> > it
> > > > > >> > > > > > before for the same purpose, and I think we
> > > > > >> > > > > > should
> > > continue
> > > > > >> > > > > > to do
> > > > > >> > so.
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > >> > >
> > > > > >> > > > wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > > > So, I agree a space would be helpful.
> > > > > >> > > > > > > > Although
> it's
> > > old
> > > > > >> > > > > > > > school
> > > > > >> > and
> > > > > >> > > > > > > > inconvenient, the mailing list is the
> > > > > >> > > > > > > > canonical
> > place
> > > > > >> > > > > > > > for
> > > > > >> > > > discussion.
> > > > > >> > > > > > > > We currently use GitHub issues a lot, but
> > > > > >> > > > > > > > that's
> > > copied
> > > > > >> > > > > > > > to a
> > > > > >> > > > mailing
> > > > > >> > > > > > > > list (as is our old JIRA space), so if people
> > > > > >> > > > > > > > want
> > to
> > > > > >> > participate
> > > > > >> > > > > > > > without a GitHub account, they can still do that.
> > > There
> > > > > >> > > > > > > > are
> > > > > >> > certain
> > > > > >> > > > > > > > options that are perhaps less convenient,
> > > > > >> > > > > > > > such as
> > just
> > > > > >> > > > > > > > using
> > > > > >> > the
> > > > > >> > > > > > > > mailing list and our dev SVN space, but still
> > > > > >> > > > > > > > more appropriate
> > > > > >> > than
> > > > > >> > > > > > > > options that would be less ubiquitous for
> potential
> > > > > >> > participants.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I think the ASF Confluence is probably fine,
> > > > > >> > > > > > > > for storing,
> > > > > >> > editing,
> > > > > >> > > > and
> > > > > >> > > > > > > > collaborating on shared documents, but
> > > > > >> > > > > > > > decisions
> > about
> > > > > >> > > > > > > > those
> > > > > >> > would
> > > > > >> > > > > > > > still need to be done on the mailing list. If
> > > > > >> > > > > > > > I remember
> > > > > >> > > > correctly, we
> > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > >> > > > favor
> > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > >> > > > > > > > mis-remembering, but
> > > > > >> > I
> > > > > >> > > > think
> > > > > >> > > > > > > > this is the case. It might explain why you
> > > > > >> > > > > > > > can't
> > > create
> > > > > >> > > > > > > > a
> > > > > >> > > > Confluence
> > > > > >> > > > > > > > space.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > My preference would be to just use the
> > > > > >> > > > > > > > website. I
> > > think
> > > > > >> > > > > > > > it's
> > > > > >> > fine
> > > > > >> > > > to
> > > > > >> > > > > > > > have a dev / design area of the website, and
> > > > > >> > > > > > > > we
> can
> > > > > >> > > > > > > > discuss on
> > > > > >> > > > GitHub
> > > > > >> > > > > > > > issues for the accumulo-website repo. That is
> > > > > >> > > > > > > > a
> bit
> > > > > >> > > > > > > > less
> > > > > >> > convenient
> > > > > >> > > > > > > > than Confluence if it's used heavily, but
> > > > > >> > > > > > > > it's
> more
> > > > > >> > > > > > > > convenient
> > > > > >> > in
> > > > > >> > > > the
> > > > > >> > > > > > > > sense that it's more accessible and fits more
> > > > > >> > > > > > > > in
> > line
> > > > > >> > > > > > > > with our
> > > > > >> > > > current
> > > > > >> > > > > > > > mode of operation. Plus, when a document is
> > > > > >> > > > > > > > final,
> > > it's
> > > > > >> > > > > > > > easy to
> > > > > >> > > > link
> > > > > >> > > > > > > > to from our documentation, without making
> > > > > >> > > > > > > > users
> jump
> > > to
> > > > > >> > > > > > > > another service to view docs.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I would be opposed to using GitHub wiki or a
> > > > > >> > > > > > > > new
> git
> > > > repo.
> > > > > >> > > > > > > > We
> > > > > >> > have
> > > > > >> > > > > > > > enough repos. Although it seems like they are
> free,
> > > > > >> > > > > > > > there is
> > > > > >> > still
> > > > > >> > > > a
> > > > > >> > > > > > > > lot of boilerplate work to maintain them,
> > > > > >> > > > > > > > from
> > > managing
> > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md,
> > > > > >> > > > > > > > etc.,
> to
> > > > > >> > .asf.yaml, to
> > > > > >> > > > > > > > README, to keeping copyright dates updated in
> > > > > >> > > > > > > > the NOTICE file,
> > > > > >> > and
> > > > > >> > > > > > > > more.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > In summary, my preference:
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss
> > > > > >> > > > > > > > on GH issues and
> > > > > >> > > > mailing
> > > > > >> > > > > > > > list (strongly preferred) 2. Confluence,
> > > > > >> > > > > > > > discuss
> on
> > > > > >> > > > > > > > mailing list (prefer over other
> > > > > >> > options,
> > > > > >> > > > but
> > > > > >> > > > > > > > not a fan)
> > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list
> > > > > >> > > > > > > > (strongly prefer not
> > > > > >> > to use
> > > > > >> > > > > > this
> > > > > >> > > > > > > > option)
> > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> mailing
> > > > > >> > > > > > > > list
> > > > > >> > (strongly
> > > > > >> > > > > > > > prefer not to use this option)
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > >> > edcoleman@apache.org>
> > > > > >> > > > > > wrote:
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > Currently, asf cannot create new wiki's
> > > > > >> > > > > > > > > because
> > of a
> > > > > >> > Confluence
> > > > > >> > > > > > issue (
> > > > > >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-2
> > > > > >> > > > > > > > 4291
> )
> > I
> > > > > >> > > > > > > > chatted
> > > > > >> > with
> > > > > >> > > > > > infra
> > > > > >> > > > > > > > and in response they created that issue.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > To expand on this discussion, I would like
> > > > > >> > > > > > > > > to
> toss
> > > > > >> > > > > > > > > out
> > > > > >> > another
> > > > > >> > > > > > > > alternative to discuss / explore. What if we
> used a
> > > > > >> > > > > > > > separate
> > > > > >> > > > GitHub
> > > > > >> > > > > > > > project, something like Accumulo-Design,
> > > > > >> > > > > > > > just
> like
> > > > > >> > accumulo-proxy
> > > > > >> > > > and
> > > > > >> > > > > > > > accumulo-examples. As a separate project, it
> would
> > be
> > > > > >> > available
> > > > > >> > > > for
> > > > > >> > > > > > > > collaboration for the community, but remain
> separate
> > > > > >> > > > > > > > from main
> > > > > >> > > > project
> > > > > >> > > > > > and
> > > > > >> > > > > > > > the website to keep current code /
> > > > > >> > > > > > > > documentation / design
> > > > > >> > clearly
> > > > > >> > > > > > separate
> > > > > >> > > > > > > > from speculative design discussions. As a
> project:
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > - document history would be preserved with
> > > > > >> > > > > > > > > git
> > > commit
> > > > > >> > history.
> > > > > >> > > > > > > > > - document collaboration could be done with
> normal
> > > PR
> > > > > >> > > > submissions /
> > > > > >> > > > > > > > reviews.
> > > > > >> > > > > > > > > - issues could be used to discuss design
> aspects,
> > > > > >> > > > > > > > > capturing
> > > > > >> > the
> > > > > >> > > > > > comment
> > > > > >> > > > > > > > history.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > The biggest downside is that it would be
> > > > > >> > > > > > > > > yet
> > another
> > > > > >> > > > > > > > > project
> > > > > >> > to
> > > > > >> > > > > > follow /
> > > > > >> > > > > > > > track.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > For me, I think the issue is that we need a
> > public,
> > > > > >> > collaborative
> > > > > >> > > > > > space
> > > > > >> > > > > > > > to hold design discussions. Neither the main
> project
> > > or
> > > > > >> > > > > > > > the
> > > > > >> > > > web-site
> > > > > >> > > > > > seem
> > > > > >> > > > > > > > quite appropriate and Confluence seems to
> > > > > >> > > > > > > > lack the
> > > > > >> > collaboration
> > > > > >> > > > that
> > > > > >> > > > > > can
> > > > > >> > > > > > > > be achieved with github.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > We need a space to capture the redesign and
> > whatever
> > > > > >> > > > > > > > > we
> > > > > >> > select
> > > > > >> > > > can be
> > > > > >> > > > > > > > made to work - I'm just wondering what
> > > > > >> > > > > > > > provides
> the
> > > > > >> > > > > > > > easiest
> > > > > >> > forum
> > > > > >> > > > to
> > > > > >> > > > > > build
> > > > > >> > > > > > > > a collaborative space for the Accumulo community.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > Ed Coleman
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net
> > wrote:
> > > > > >> > > > > > > > > > Circling back on this issue - I agree
> > > > > >> > > > > > > > > > that
> > > comments
> > > > > >> > > > > > > > > > and
> > > > > >> > such
> > > > > >> > > > make
> > > > > >> > > > > > > > sense for internal design documents. I'm
> > > > > >> > > > > > > > going to create an
> > > > > >> > INFRA
> > > > > >> > > > > > ticket
> > > > > >> > > > > > > > for a cwiki space for Accumulo unless there
> > > > > >> > > > > > > > are
> any
> > > > > >> objections.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > -----Original Message-----
> > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki
> > > > > >> > > > > > > > > > in
> > > > asf.yaml?
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > As mentioned, wikis can provide a
> > > > > >> > > > > > > > > > streamlined collaborative
> > > > > >> > > > editing
> > > > > >> > > > > > > > workflow that's less labor intensive than
> updating a
> > > > > >> website.
> > > > > >> > They
> > > > > >> > > > can
> > > > > >> > > > > > > > promote collaboration by providing specific
> tooling
> > to
> > > > > >> > > > > > > > support
> > > > > >> > > > > > comments,
> > > > > >> > > > > > > > revisions and iteration.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > In terms of preservation, GH wikis act
> > > > > >> > > > > > > > > > just
> like
> > > > > >> > > > > > > > > > any other
> > > > > >> > Git
> > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > git@github.com
> > > > > :
> > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > >> > > > > > > > > > IIRC the pages are just GH flavored markdown.
> > > There
> > > > > >> > > > > > > > > > are at
> > > > > >> > > > least a
> > > > > >> > > > > > few
> > > > > >> > > > > > > > Apache projects using them.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > However, GH wikis lack some features that
> > > > > >> > > > > > > > > > I
> feel
> > > > > >> > > > > > > > > > are
> > > > > >> > important
> > > > > >> > > > to
> > > > > >> > > > > > > > support collaborative authoring. For example,
> > > > > >> > > > > > > > the ability to
> > > > > >> > > > comment
> > > > > >> > > > > > and
> > > > > >> > > > > > > > discuss specific passages in a document is a
> feature
> > > > > >> > > > > > > > that's
> > > > > >> > > > present in
> > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come
> > > > > >> > > > > > > > appreciate
> > this
> > > > > >> > > > > > > > this in
> > > > > >> > my
> > > > > >> > > > google
> > > > > >> > > > > > > > docs and office workflows, so expect that it
> > > > > >> > > > > > > > would
> > be
> > > > > >> > > > > > > > useful
> > > > > >> > for
> > > > > >> > > > > > Accumulo
> > > > > >> > > > > > > > design discussions too.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith
> > > > > >> > > > > > > > > > Turner <
> > > > > >> > > > kturner@apache.org>
> > > > > >> > > > > > > > wrote:
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > documents,
> > > > > >> > > > > > > > > > > I think
> > > > > >> > it
> > > > > >> > > > > > would be
> > > > > >> > > > > > > > > > > less cumbersome than the website and we
> > > > > >> > > > > > > > > > > can always link
> > > > > >> > from
> > > > > >> > > > the
> > > > > >> > > > > > > > > > > website and issues to the wiki. I
> > > > > >> > > > > > > > > > > think its
> > ok
> > > > > >> > > > > > > > > > > to give
> > > > > >> > it a
> > > > > >> > > > try
> > > > > >> > > > > > and
> > > > > >> > > > > > > > > > > abandon it in the future, if abandoned
> > > > > >> > > > > > > > > > > would
> > > just
> > > > > >> > > > > > > > > > > need to
> > > > > >> > > > > > properly
> > > > > >> > > > > > > > > > > communicate that. The content should
> > > > > >> > > > > > > > > > > be
> > > archived
> > > > > >> > > > > > > > > > > in
> > > > > >> > Apache
> > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does not
> > > > > >> > > > > > > > > > > do
> that
> > > > > >> > > > > > > > > > > then we
> > > > > >> > should
> > > > > >> > > > > > not use
> > > > > >> > > > > > > > > > > it. If GH wiki is not an option then
> > > > > >> > > > > > > > > > > could
> > try
> > > > > cwiki.
> > > > > >> > > > > > > > > > >
> > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > >> > > > wrote:
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I reverted the change. I didn't think
> > > > > >> > > > > > > > > > > > it
> > would
> > > > > >> > > > > > > > > > > > be a big
> > > > > >> > > > deal,
> > > > > >> > > > > > but
> > > > > >> > > > > > > > if
> > > > > >> > > > > > > > > > > > it
> > > > > >> > > > > > > > > > > requires discussion, then let's discuss it.
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I'm looking for a place to host
> information
> > > > > >> > > > > > > > > > > > related to
> > > > > >> > > > internal
> > > > > >> > > > > > > > > > > > design
> > > > > >> > > > > > > > > > > discussions. I envision these to be
> > > > > >> > > > > > > > > > > living documents that
> > > > > >> > > > will be
> > > > > >> > > > > > > > > > > updated over time as the
> design/implementation
> > > > > >> > progresses and
> > > > > >> > > > > > that
> > > > > >> > > > > > > > > > > other committers will be able to
> > > > > >> > > > > > > > > > > comment on
> > and
> > > > > >> > > > > > > > > > > edit. I
> > > > > >> > don't
> > > > > >> > > > > > feel
> > > > > >> > > > > > > > > > > that the website is the correct place
> > > > > >> > > > > > > > > > > for
> this
> > > > > >> because:
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > discussions
> > > > > >> > > > > > > > > > > > should
> > > > > >> > go
> > > > > >> > > > on the
> > > > > >> > > > > > > > > > > > project
> > > > > >> > > > > > > > > > > website.
> > > > > >> > > > > > > > > > > > 2. Changes to the design documents
> > > > > >> > > > > > > > > > > > could
> > not
> > > > > >> > > > > > > > > > > > be seen
> > > > > >> > by
> > > > > >> > > > > > others
> > > > > >> > > > > > > > > > > > right
> > > > > >> > > > > > > > > > > away (IIRC changes to the website are
> > > > > >> > > > > > > > > > > built
> > and
> > > > > >> > available at
> > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/,
> > > > > >> > > > > > > > > > > but
> > human
> > > > > >> > intervention
> > > > > >> > > > is
> > > > > >> > > > > > > > > > > required to publish it at
> > > > > >> https://accumulo.apache.org/).
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I looked in the INFRA issues and
> > > > > >> > > > > > > > > > > > other
> > > projects
> > > > > >> > > > > > > > > > > > are
> > > > > >> > using
> > > > > >> > > > the
> > > > > >> > > > > > GH
> > > > > >> > > > > > > > > > > > Wiki
> > > > > >> > > > > > > > > > > feature and I saw no mention of backing
> > > > > >> > > > > > > > > > > it
> up
> > or
> > > > > >> > > > > > > > > > > the
> > > > > >> > > > requirement
> > > > > >> > > > > > to
> > > > > >> > > > > > > > do
> > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing
> > > > > >> > > > > > > > > > > it
> up?).
> > > It
> > > > > >> > > > > > > > > > > does
> > > > > >> > appear
> > > > > >> > > > > > that we
> > > > > >> > > > > > > > > > > would need an INFRA ticket so that they
> > > > > >> > > > > > > > > > > can modify the
> > > > > >> > GitHub
> > > > > >> > > > > > project
> > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down
> > > > > >> > > > > > > > > > > so
> that
> > > > > >> > > > > > > > > > > only
> > > > > >> > > > committers can
> > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not
> > > > > >> > > > > > > > > > > acceptable,
> > > then
> > > > > >> > > > > > > > > > > I think
> > > > > >> > > > Apache
> > > > > >> > > > > > > > > > > Confluence (
> > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > acceptable
> > > > > >> > > > alternative.
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > >> > > > > > > > > > > > From: Christopher
> > > > > >> > > > > > > > > > > > <ct...@apache.org>
> > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023
> > > > > >> > > > > > > > > > > > 4:41 AM
> > > > > >> > > > > > > > > > > > To: accumulo-dev
> > > > > >> > > > > > > > > > > > <dev@accumulo.apache.org
> >
> > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> updated:
> > > > > >> > > > > > > > > > > > Enable
> > > > > >> > Github
> > > > > >> > > > > > wiki in
> > > > > >> > > > > > > > > > > asf.yaml
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I don't recall a discussion about
> > > > > >> > > > > > > > > > > > this
> > change,
> > > > > >> > > > > > > > > > > > but I
> > > > > >> > think
> > > > > >> > > > it
> > > > > >> > > > > > goes
> > > > > >> > > > > > > > > > > against previous efforts to make the
> > > > > >> > > > > > > > > > > website
> > the
> > > > > >> > > > > > > > > > > one
> > > > > >> > > > canonical
> > > > > >> > > > > > > > > > > location for our documentation. I don't
> > > > > >> > > > > > > > > > > even think infra
> > > > > >> > is
> > > > > >> > > > > > backing
> > > > > >> > > > > > > > up
> > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a
> record
> > > of
> > > > > >> > > > > > > > > > > the
> > > > > >> > wiki
> > > > > >> > > > > > contents
> > > > > >> > > > > > > > in
> > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is
> backed
> > > up
> > > > > >> > > > > > > > > > > to
> > > > > >> > GitBox
> > > > > >> > > > and
> > > > > >> > > > > > the
> > > > > >> > > > > > > > > > > issue tracker, which CCs the
> > > > > >> > > > > > > > > > > notifications
> > > list).
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > In short, I think this should be
> > > > > >> > > > > > > > > > > > reverted
> > and
> > > > > >> > > > > > > > > > > > we
> > > > > >> > should not
> > > > > >> > > > > > use the
> > > > > >> > > > > > > > > > > GitHub wiki. If we need to store
> > > > > >> > > > > > > > > > > documents
> in
> > a
> > > > > >> > > > > > > > > > > version
> > > > > >> > > > > > controlled
> > > > > >> > > > > > > > > > > way, we can store them on the website,
> > > > > >> > > > > > > > > > > or in
> > our
> > > > > >> > project's
> > > > > >> > > > SVN
> > > > > >> > > > > > dev
> > > > > >> > > > > > > > > > > space. The wiki is just another place
> > > > > >> > > > > > > > > > > people would have
> > > > > >> > to
> > > > > >> > > > > > follow if
> > > > > >> > > > > > > > > > > they want to participate, and I don't
> > > > > >> > > > > > > > > > > think
> > that
> > > > > >> > > > > > > > > > > serves
> > > > > >> > us.
> > > > > >> > > > > > > > Therefore,
> > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > >> > wrote:
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > This is an automated email from the
> > > > > >> > > > > > > > > > > > > ASF dual-hosted
> > > > > >> > git
> > > > > >> > > > > > > > repository.
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch
> > > > > >> > > > > > > > > > > > > main
> in
> > > > > >> > > > > > > > > > > > > repository
> > > > > >> > > > > > > > > > > > >
> > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > >> > > > > > > > > > > > > git
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > The following commit(s) were added
> > > > > >> > > > > > > > > > > > > to
> > > > > >> > refs/heads/main by
> > > > > >> > > > this
> > > > > >> > > > > > > > push:
> > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github
> > > > > >> > > > > > > > > > > > > wiki
> in
> > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > >> > > > > > ae8a817e7b is
> > > > > >> > > > > > > > > > > > > described below
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > commit
> > > > > >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c
> > > > > >> > > > > > > > > > > > > 0e677
> > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> dlmarion@apache.org>
> > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10
> > > > > >> > > > > > > > > > > > > 2023
> -0500
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > >> > > > > > > > > > > > > --- .asf.yaml | 2 +-
> > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml
> > > > > >> > > > > > > > > > > > > index
> > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > >> > > > > > > > > > > > > 100644
> > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > >> > > > > > > > > > > > > - big-data
> > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > >> > > > > > > > > > > > > features:
> > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > >> > > > > > > > > > > > > issues: true
> > > > > >> > > > > > > > > > > > > projects: true
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > >
> > > > > >> > > > > >
> > > > > >> > > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
RE: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by dev1 <de...@etcoleman.com>.
The apache wiki has been created at https://cwiki.apache.org/confluence/display/ACCUMULO/Apache+Accumulo+Home
Dave noticed that other project were able to request manual creation instead of using self-serve and asked infra to create the space.
Ed Coleman
-----Original Message-----
From: Christopher <ct...@apache.org>
Sent: Thursday, March 16, 2023 9:39 AM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
Those aren't differences (either not a difference at all, or not a
meaningful one).
1. Immediate availability. GitHub already renders the content
immediately... this is why we can view Markdown files like README and
other file types directly in the repo navigation. The non-immediate
view on the website is a secondary view... but even that takes mere
seconds to build and render.
2. Not publishing draft/WIP design documents on the website: whether
we have the rendered files accessible at
confluence.apache.org/accumulo/designs or accumulo.apache.org/designs,
we're still publishing to the exact same extent. The files are being
made publicly available to developers / potential contributors, but
not promoted to users in draft form. It's the same thing. Presumably,
in our developer docs, we would link to the confluence/GitHub wiki so
other devs can find it. This is the same as linking to our
accumulo-website repo or to the /designs folder on our website. The
only difference that matters for publication is whether we make it
available to developers or if we promote it to users. But, linking to
one site for developers vs. another site for developers is not a
difference in any way that is meaningful.
Again, I will point to an existing precedent for precisely the same
thing (working document for a feature design) at
https://github.com/apache/accumulo-website/blob/main/design/system-snapshot.md
; This was added using a PR
https://github.com/apache/accumulo-website/pull/163 with
comments/discussion that triggered notifications to our mailing lists
for participation opportunity, was rendered in Markdown immediately,
and ultimately got merged to a folder that does not have a link
anywhere on the website, so we don't promote it in draft form to
users. The workflow followed for that hits *all* of the stated
requirements, is an existing precedent, was quite convenient, *and*
has the added benefit of being consolidated in the same repo as other
docs. It also is mirrored to ASF's gitbox and would have notifications
triggered to the mailing list for any non-GitHub users, so it doesn't
require any separate accounts like Confluence or GitHub to
participate. It also matches our existing collaboration workflow,
which I think is important for a small project like ours, so we don't
spread ourselves too thin.
As for the downsides of putting the Wiki in a subfolder in the project:
1. The .asf.yaml doesn't seem to support configuring it to be based on
a subfolder, so this would require getting INFRA involved for
changes... which I'd rather not do. I'd rather do things that are
self-serve as much as possible. I did briefly look into this, and I
also can't find GitHub documentation for how to put a wiki in a
subfolder. I found the docs for putting the GitHub Pages website in a
subfolder, but that's different, and not what anybody has proposed.
2. It would have to be put in a separate repo, rather than the main
accumulo repo, because putting it in the main repo would mean we'd
have to work around it for the build environment (it would also
undermine the whole effort to strip the docs/ directory out of the
main repo). If we put it in an existing repo, then the best candidate
would be the accumulo-website repo anyway, and we'd have to either
ignore that directory during the website build, or it would end up on
the website anyway... which is what I proposed, but with the extra
complexity of having a separate wiki feature tied to it.
I'm not saying the website repo as I've proposed is a 100% perfect
solution... but I think of all the options, it's the best for the
project long term. I don't think we need a specialty product or
tailored platform to get what we want. I know people have their own
preferences... but on the technical merits, I still think this is the
best option.
On Thu, Mar 16, 2023 at 8:23 AM Dave Marion <dm...@gmail.com> wrote:
>
> This was just something I found to answer the issue of notifications,
> issues, and PRs. I think the main difference is that it's immediately
> available on the GitHub site for viewing vs having to wait for it to be
> published to the website and that we're not publishing draft or WIP design
> documents to the website. I still think that Confluence is a better option
> regarding comments and discussion, hopefully infra can figure that out.
>
> On Thu, Mar 16, 2023 at 7:51 AM Christopher <ct...@apache.org> wrote:
>
> > Isn't that basically the same as how the website repo works? How would
> > that be different then?
> >
> > On Wed, Mar 15, 2023 at 2:55 PM Dave Marion <dm...@gmail.com> wrote:
> > >
> > > It looks like we could generate the GH wiki from a folder in the source
> > > code. This would allow for issues and PRs. Just a thought.
> > >
> > > Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
> > >
> > https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
> > >
> > > On Wed, Mar 15, 2023 at 2:16 PM Christopher <ct...@apache.org> wrote:
> > >
> > > > It seems like there's a majority consensus of those engaged. No need
> > for a
> > > > vote, but I think the question about notifications should be addressed
> > > > first.
> > > >
> > > > On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
> > > > christopher.l.shannon@gmail.com> wrote:
> > > >
> > > > > I'm +1 to using some kind of wiki so if we can't use Confluence then
> > GH
> > > > > sounds fine to me. Do we need to take a formal vote for using the
> > Github
> > > > > wiki or is there enough consensus already?
> > > > >
> > > > > On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > +1 for the GH wiki with major discussions still being fed into, or
> > > > > > originated on the mailing lists.
> > > > > >
> > > > > > As a side question, if there is a lengthy discussion on a GH
> > issue, is
> > > > it
> > > > > > standard practice to just recap that in a mailing list message?
> > > > > > Or is there a more "formal" inclusion process to follow?
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > I don't think the workflow I proposed about using PRs and
> > discussion
> > > > on
> > > > > > > tickets, etc. and the accompanying arguments about keeping things
> > > > > > > consolidated and accessible to potential contributors not
> > > > participating
> > > > > > on
> > > > > > > GitHub, were really challenged at all. However, since I seem to
> > be
> > > > the
> > > > > > only
> > > > > > > one advocating for using the website, to keep things
> > centralized, as
> > > > > per
> > > > > > > previous attempts to consolidate documentation, I won't fight
> > the use
> > > > > of
> > > > > > > GitHub wiki. But I do want to make it clear that we're
> > proceeding in
> > > > > that
> > > > > > > direction under my objection (-0), and that I'm not convinced
> > this is
> > > > > the
> > > > > > > best path forward. Hopefully, I will be proven wrong in time.
> > > > > > >
> > > > > > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com>
> > wrote:
> > > > > > >
> > > > > > > > > At this point, I think we should move forward with a GH wiki
> > and
> > > > > then
> > > > > > > we
> > > > > > > > can re-evaluate things once the Apache confluence issue is
> > sorted
> > > > > out.
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com>
> > wrote:
> > > > > > > >
> > > > > > > > > I just tried (Wed, 3/15) and still received the same error.
> > I
> > > > > asked
> > > > > > on
> > > > > > > > > the infra slack channel and they replied that they are still
> > > > > working
> > > > > > to
> > > > > > > > > determine what the issue is - signs are pointing to something
> > > > > inside
> > > > > > of
> > > > > > > > > confluence, but no progress.
> > > > > > > > >
> > > > > > > > > At this point, I think we should move forward with a GH wiki
> > and
> > > > > then
> > > > > > > we
> > > > > > > > > can re-evaluate things once the Apache confluence issue is
> > sorted
> > > > > > out.
> > > > > > > > >
> > > > > > > > > Ed Coleman
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Dave Marion <dm...@gmail.com>
> > > > > > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > >
> > > > > > > > > Looking at the Infra slack channel response, one of the
> > responses
> > > > > in
> > > > > > > the
> > > > > > > > > channel said that "it's some sort of db corruption according
> > to
> > > > > > > > Atlassian".
> > > > > > > > > Doesn't sound good....
> > > > > > > > >
> > > > > > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <
> > dmarion18@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > > > > > unresolved
> > > > > > > > > > and the only comment on the ticket is one that Ed added two
> > > > days
> > > > > > ago
> > > > > > > > > > requesting an ACCUMULO wiki space.
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com>
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> I do not see any comments in the infa slack channel - so
> > no
> > > > > > updates
> > > > > > > > > >> for now.
> > > > > > > > > >>
> > > > > > > > > >> -----Original Message-----
> > > > > > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > > > > > >> To: dev@accumulo.apache.org
> > > > > > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > > >>
> > > > > > > > > >> Right, I was just curious if there was any follow-up as I
> > > > think
> > > > > Ed
> > > > > > > > > >> said that it was going to be discussed by the INFRA team
> > > > > > yesterday.
> > > > > > > > > >> There is at least one other recent ticket (
> > > > > > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > > > > > selfserve
> > > > > > > > > >> had an issue and the INFRA team created the space
> > manually.
> > > > > > > > > >>
> > > > > > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> > > > > ctubbsii@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >> > You can track that issue at
> > > > > > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > > > > > >> >
> > > > > > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > > > > > dmarion18@gmail.com>
> > > > > > > > > >> wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > Ed,
> > > > > > > > > >> > >
> > > > > > > > > >> > > Any update from INFRA on being able to create
> > confluence
> > > > > > > pages?
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > > > > > ctubbsii@apache.org
> > > > > > > >
> > > > > > > > > >> wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > > We've definitely used the website for more than
> > that. We
> > > > > use
> > > > > > > it
> > > > > > > > > >> > > > to document things for users, help developers know
> > how
> > > > to
> > > > > > > > > >> > > > contribute, store drafts of designs, share user
> > stories
> > > > > via
> > > > > > > > > >> > > > blogs, do release announcements, and more. There's
> > > > > > definitely
> > > > > > > > > >> > > > space on the website to do this kind of thing, if we
> > > > want
> > > > > > to.
> > > > > > > > > >> > > > We've used it that way before. If you only see it
> > as a
> > > > > place
> > > > > > > > > >> > > > "for user consumption after everything has been
> > > > > finalized",
> > > > > > > > > >> > > > then you're missing out on the other ways we
> > currently
> > > > use
> > > > > > the
> > > > > > > > > >> > > > site, and the ways we've used it in
> > > > > > > > > >> the past.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > With the website, most of the collaboration would
> > happen
> > > > > in
> > > > > > > the
> > > > > > > > > >> > > > GH issues about proposed designs or changes to
> > designs,
> > > > > just
> > > > > > > > > >> > > > like we do today with code or other documentation,
> > which
> > > > > > > > > >> > > > everybody is used to. I agree it's not as good as
> > Google
> > > > > > Docs
> > > > > > > > > >> > > > for on-the-fly comments/annotations, but I don't
> > think
> > > > > > > > > >> > > > Confluence or Wiki are as good as that either, and
> > > > Google
> > > > > > Docs
> > > > > > > > > isn't really an option...
> > > > > > > > > >> > > > unless you just want to link to it in the mailing
> > list
> > > > and
> > > > > > > > > >> > > > stick to Google Docs from your personal Google
> > account,
> > > > > > until
> > > > > > > > > >> > > > it's ready for publication, which would also be fine
> > > > (any
> > > > > > > > > >> > > > interested persons can simply request write access
> > by
> > > > > > replying
> > > > > > > > > >> > > > to the message where
> > > > > > > > > >> you shared the link)..
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > We are a much smaller project than many others, and
> > we
> > > > > have
> > > > > > > > > >> > > > previously suffered from having stuff too spread
> > out.
> > > > Even
> > > > > > if
> > > > > > > > > >> > > > other projects find a separate space valuable for
> > them,
> > > > > I'm
> > > > > > > not
> > > > > > > > > >> > > > sure it's best for the Accumulo project. While I
> > think
> > > > > it's
> > > > > > > > > >> > > > useful to examine what other projects do, I do
> > think we
> > > > > > should
> > > > > > > > > >> > > > be careful to adopt anything just because others
> > find it
> > > > > > > > > convenient for them.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Confluence is my second choice, but with a big gap
> > > > between
> > > > > > it
> > > > > > > > > >> > > > and my first choice.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > On a personal note: I hate using Confluence,
> > because I
> > > > > think
> > > > > > > > > >> > > > the navigation is highly unintuitive, as is the
> > > > > permissions
> > > > > > > > > >> > > > model, and I don't like the idea of learning yet
> > another
> > > > > > > > > >> > > > wiki-syntax (though I've read Confluence supports
> > some
> > > > > > limited
> > > > > > > > > >> > > > Markdown, but probably not the same as
> > GitHub/Jekyll). I
> > > > > > also
> > > > > > > > > >> > > > do not want to set up custom notifications for
> > watching
> > > > > yet
> > > > > > > > > >> > > > another space. If we use Confluence, I will probably
> > > > > > > contribute
> > > > > > > > > >> > > > very infrequently there because of my frustrations
> > with
> > > > > > having
> > > > > > > > > >> > > > used it before. However, that would be my choice,
> > and
> > > > > should
> > > > > > > > > >> > > > not be a reason the project chooses one over
> > another.
> > > > I'm
> > > > > > > > > >> > > > sharing my personal opinion only because it is
> > > > influencing
> > > > > > my
> > > > > > > > > >> > > > opinion about the website being more accessible,
> > via our
> > > > > > > > > >> > > > current GitHub PR/issue/Markdown workflows, and I
> > wonder
> > > > > how
> > > > > > > > > >> > > > many other potential contributors would feel
> > similarly.
> > > > > It's
> > > > > > > > > >> > > > hard to know, since it seems like a lot of this is
> > > > > > subjective,
> > > > > > > > > >> > > > and is going to come down to a consensus of personal
> > > > > > > > > >> preferences.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > > > > > >> > > > <dm...@gmail.com>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > I don't see the website as an area where we would
> > have
> > > > > > > > > >> > > > > collaborative discussions about an idea. For
> > example,
> > > > > > making
> > > > > > > > > >> > > > > comments and
> > > > > > > > > >> > suggestions
> > > > > > > > > >> > > > on
> > > > > > > > > >> > > > > a document like you can do in Google Docs. I see
> > the
> > > > > > website
> > > > > > > > > >> > > > > as a
> > > > > > > > > >> > place
> > > > > > > > > >> > > > > where items are documented for user consumption
> > after
> > > > > > > > > >> > > > > everything has
> > > > > > > > > >> > been
> > > > > > > > > >> > > > > finalized. I'm not trying to create a private
> > > > discussion
> > > > > > > > > >> > > > > area, I
> > > > > > > > > >> > think
> > > > > > > > > >> > > > > anyone can see the wiki (but I think anonymous
> > > > comments
> > > > > > are
> > > > > > > > > >> > > > > disabled
> > > > > > > > > >> > due
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > spam issues). I see no issue with putting
> > > > > work-in-progress
> > > > > > > > > >> > > > > documents
> > > > > > > > > >> > on a
> > > > > > > > > >> > > > > wiki and referencing them via emails to the dev
> > list.
> > > > I
> > > > > > > think
> > > > > > > > > >> > > > > this is
> > > > > > > > > >> > > > done
> > > > > > > > > >> > > > > in a lot of other projects. Non-committers that
> > don't
> > > > > have
> > > > > > > > > >> > > > > access to
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > wiki and want to make comments, suggestions, and
> > ask
> > > > > > > > > >> > > > > questions can
> > > > > > > > > >> > do so
> > > > > > > > > >> > > > > via the mailing list. I think it's also possible
> > that
> > > > > > people
> > > > > > > > > >> > > > > can get confluence accounts (see
> > > > > > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > > > > > >> > > > > so if a non-committer wanted to participate they
> > > > could.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > > > > > >> > > > > <ct...@apache.org>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > > > > > >> > > > > > <dm...@gmail.com>
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > I'm opposed to using the website for the
> > reasons I
> > > > > > > > > >> > > > > > > specified
> > > > > > > > > >> > > > earlier, so
> > > > > > > > > >> > > > > > it
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Your reasons that I saw were:
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > 1. I don't think internal design discussions
> > > > should
> > > > > go
> > > > > > > on
> > > > > > > > > >> > > > > > > the
> > > > > > > > > >> > project
> > > > > > > > > >> > > > > > website.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > That doesn't look to me like a reason. That
> > appears
> > > > to
> > > > > > > just
> > > > > > > > > >> > > > > > be
> > > > > > > > > >> > stating
> > > > > > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > 2. Changes to the design documents could not
> > be
> > > > seen
> > > > > > by
> > > > > > > > > >> > > > > > > others
> > > > > > > > > >> > right
> > > > > > > > > >> > > > > > away (IIRC changes to the website are built and
> > > > > > available
> > > > > > > > > >> > > > > > at https://accumulo.staged.apache.org/, but
> > human
> > > > > > > > > >> > > > > > intervention is
> > > > > > > > > >> > > > required
> > > > > > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > What do you mean by "others" here? Do you mean
> > > > > "users",
> > > > > > as
> > > > > > > > > >> > > > > > opposed
> > > > > > > > > >> > to
> > > > > > > > > >> > > > > > "developers/contributors"? The ASF draws a
> > > > distinction
> > > > > > > > > >> > > > > > between "developers/contributors" and "users"
> > as it
> > > > > > > > > >> > > > > > pertains to official releases. Releases are
> > intended
> > > > > to
> > > > > > be
> > > > > > > > > >> > > > > > consumed by users, and pre-release stuff is
> > intended
> > > > > to
> > > > > > be
> > > > > > > > > >> > > > > > collaborative, open to all potential
> > > > > > > > > >> > > > > > developers/contributors. Very very rarely are
> > things
> > > > > > > > > >> > > > > > reserved exclusively for committers. We don't
> > even
> > > > > have
> > > > > > a
> > > > > > > > > >> > > > > > private committers space (the private mailing
> > list
> > > > is
> > > > > > > > > >> > > > > > PMC-private, not committer-private). Having a
> > > > > > distinction
> > > > > > > > > >> > > > > > between users and
> > > > > > > > > >> > developers
> > > > > > > > > >> > > > > > doesn't mean we can't publish things on the
> > > > website...
> > > > > > it
> > > > > > > > > >> > > > > > just
> > > > > > > > > >> > means
> > > > > > > > > >> > > > > > that we should be careful about how we do it,
> > which
> > > > is
> > > > > > the
> > > > > > > > > >> > > > > > same
> > > > > > > > > >> > care
> > > > > > > > > >> > > > > > we should take regardless of where we put it.
> > > > > > > Specifically,
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > care
> > > > > > > > > >> > > > > > we need to take is to avoid marketing
> > pre-release
> > > > > > content
> > > > > > > > > >> > > > > > to
> > > > > > > > > >> users.
> > > > > > > > > >> > > > > > One way we can exercise this care for content
> > on our
> > > > > > > > > >> > > > > > website is
> > > > > > > > > >> > that
> > > > > > > > > >> > > > > > we can avoid sharing these unpolished designs by
> > > > > simply
> > > > > > > not
> > > > > > > > > >> > > > > > linking them on the site, or by placing them in
> > an
> > > > > area
> > > > > > > > > >> > > > > > that is clearly
> > > > > > > > > >> > marked
> > > > > > > > > >> > > > > > as intended for devs. But, we have no similar
> > > > > > distinction
> > > > > > > > > >> > > > > > between committers and non-committer devs for
> > which
> > > > we
> > > > > > > > > >> > > > > > should avoid sharing pre-release content under
> > > > > > > development.
> > > > > > > > > >> > > > > > In fact, it is the
> > > > > > > > > >> > opposite...
> > > > > > > > > >> > > > > > we should be developing openly so as to allow
> > room
> > > > for
> > > > > > > > > >> > non-committers
> > > > > > > > > >> > > > > > to become committers through participation in
> > > > > > development
> > > > > > > > > >> > activities.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > As for the staging/publication of the website,
> > > > that's
> > > > > > just
> > > > > > > > > >> > > > > > a
> > > > > > > > > >> > mechanic
> > > > > > > > > >> > > > > > for verifying the website isn't broken before we
> > > > serve
> > > > > > it.
> > > > > > > > > >> > > > > > It's
> > > > > > > > > >> > not a
> > > > > > > > > >> > > > > > mechanism for keeping things internal vs.
> > shared and
> > > > > > > > > >> > > > > > doesn't have anything to do with the separation
> > > > > between
> > > > > > > > > >> > > > > > devs and users. We
> > > > > > > > > >> > already
> > > > > > > > > >> > > > > > publish Draft contents to the website, as well
> > as
> > > > > > > > > >> > developer-specific
> > > > > > > > > >> > > > > > documentation not intended for users.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > We've even specifically published
> > work-in-progress
> > > > > > design
> > > > > > > > > >> > > > > > documents there, of the same type that seems to
> > be
> > > > the
> > > > > > > > > >> > > > > > basis of this conversation (
> > > > > > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > > > > > >> > I
> > > > > > > > > >> > > > > > would strongly prefer us to continue to do it
> > this
> > > > > way,
> > > > > > > > > >> > > > > > rather than create a new space, and have these
> > kinds
> > > > > of
> > > > > > > > > >> > > > > > things scattered in multiple places.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > If, on the other hand, you intend to say that
> > these
> > > > > > should
> > > > > > > > > >> > > > > > be
> > > > > > > > > >> > private
> > > > > > > > > >> > > > > > because they aren't ready for other potential
> > > > > > > contributors,
> > > > > > > > > >> > > > > > then I would argue that we're an openly
> > developed
> > > > > > > project...
> > > > > > > > > >> > > > > > if something isn't ready to be shared with other
> > > > > > potential
> > > > > > > > > >> > > > > > contributors / developers, such that you want to
> > > > keep
> > > > > it
> > > > > > > > > >> > > > > > internal to existing committers, then it's not
> > ready
> > > > > to
> > > > > > be
> > > > > > > > > >> > > > > > contributed to the project at all... because we
> > > > don't
> > > > > > > > > >> > > > > > restrict collaboration to only existing
> > committers.
> > > > > That
> > > > > > > > > >> > > > > > would prevent others from participating and
> > > > > > > > > >> > earning
> > > > > > > > > >> > > > > > the merit to become committers, and that's not
> > > > > something
> > > > > > > we
> > > > > > > > > >> > > > > > should
> > > > > > > > > >> > be
> > > > > > > > > >> > > > > > doing. Anything that is okay to share with
> > existing
> > > > > > > > > >> > > > > > committers
> > > > > > > > > >> > should
> > > > > > > > > >> > > > > > be okay to share to other potential
> > contributors who
> > > > > > want
> > > > > > > > > >> > > > > > to participate, and should be done in a space
> > that
> > > > > > allows
> > > > > > > > > >> > > > > > them to do that. The website is a perfect space
> > for
> > > > > > that,
> > > > > > > > > >> > > > > > and has everything
> > > > > > > > > >> > we
> > > > > > > > > >> > > > > > need. I'm actually not sure about Confluence...
> > I
> > > > > > suspect
> > > > > > > > > >> > > > > > non-committers wouldn't be able to participate
> > there
> > > > > > > > > >> > > > > > because they probably can't get accounts for it.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > looks like we need to
> > > > > > > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be
> > curious
> > > > how
> > > > > > > much
> > > > > > > > > >> > > > > > > we
> > > > > > > > > >> > need to
> > > > > > > > > >> > > > use
> > > > > > > > > >> > > > > > > the mailing list during
> > > > > > > > > >> > > > > > > the design phase. We can announce meeting
> > > > > dates/times
> > > > > > on
> > > > > > > > > >> > > > > > > the
> > > > > > > > > >> > mailing
> > > > > > > > > >> > > > list
> > > > > > > > > >> > > > > > > and post links to
> > > > > > > > > >> > > > > > > meeting notes in Confluence. Ultimately,
> > decisions
> > > > > > made
> > > > > > > > > >> > > > > > > by the
> > > > > > > > > >> > people
> > > > > > > > > >> > > > > > that
> > > > > > > > > >> > > > > > > want to be involved
> > > > > > > > > >> > > > > > > will turn into pull requests against the
> > codebase
> > > > > > which
> > > > > > > > > >> > comitters can
> > > > > > > > > >> > > > > > weigh
> > > > > > > > > >> > > > > > > in on. When you say,
> > > > > > > > > >> > > > > > > "... but decisions about those would still
> > need to
> > > > > be
> > > > > > > > > >> > > > > > > done on the
> > > > > > > > > >> > > > mailing
> > > > > > > > > >> > > > > > > list." Are you saying that we need to discuss
> > > > every
> > > > > > > > > >> > > > > > > single design decision on the mailing
> > > > > > > > > >> > list?
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Yes and no. I am saying that decisions need to
> > > > happen
> > > > > on
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > mailing
> > > > > > > > > >> > > > > > list, but I agree with you that this can be
> > > > satisfied
> > > > > > > > > >> > > > > > through pull requests. I just wanted to
> > emphasize
> > > > that
> > > > > > > > > >> > > > > > regardless of where we do that pre-decision
> > > > > > collaboration,
> > > > > > > > > >> > > > > > that collaboration should not be misconstrued
> > as a
> > > > > > > decision
> > > > > > > > > >> > > > > > to
> > > > > > > > > >> accept those ideas into the project.
> > > > > > > > > >> > The
> > > > > > > > > >> > > > > > decision occurs during the PR or other activity
> > that
> > > > > > > > > >> > > > > > interfaces
> > > > > > > > > >> > with
> > > > > > > > > >> > > > > > the mailing list, subsequent to the
> > collaboration in
> > > > > the
> > > > > > > > > >> > design/idea
> > > > > > > > > >> > > > > > phase.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > As for the pre-decision collaboration space
> > we're
> > > > > > > > > >> > > > > > discussing, I
> > > > > > > > > >> > just
> > > > > > > > > >> > > > > > want to be careful that we're not creating such
> > a
> > > > > space
> > > > > > in
> > > > > > > > > >> > > > > > an exclusionary way that allows only existing
> > > > > committers
> > > > > > > to
> > > > > > > > > >> > participate,
> > > > > > > > > >> > > > > > that excludes other potential contributors.
> > This is
> > > > > > still
> > > > > > > > > >> > > > > > an openly-developed project, and we should
> > > > collaborate
> > > > > > in
> > > > > > > a
> > > > > > > > > >> > > > > > space
> > > > > > > > > >> > that is
> > > > > > > > > >> > > > > > not exclusive to existing committers, but open
> > to
> > > > > > > > > >> > > > > > non-committer contributors and potential
> > > > contributors
> > > > > as
> > > > > > > > well.
> > > > > > > > > >> > > > > > So, while we may
> > > > > > > > > >> > want
> > > > > > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > > > > > >> > > > > > consumption (an important separation that
> > relates to
> > > > > > > > > >> > > > > > official ASF releases), we
> > > > > > > > > >> > should
> > > > > > > > > >> > > > > > not be drawing a line between committer-devs as
> > > > > > "internal"
> > > > > > > > > >> > > > > > and contributor-devs as "external". The website,
> > > > with
> > > > > > its
> > > > > > > > > >> > > > > > own issue tracker, the ability to render
> > markdown,
> > > > do
> > > > > > > > > >> > > > > > reviews, and collaboratively edit, seems like
> > the
> > > > > ideal
> > > > > > > > > >> > > > > > place to me. We've used
> > > > > > > > > >> > it
> > > > > > > > > >> > > > > > before for the same purpose, and I think we
> > should
> > > > > > > continue
> > > > > > > > > >> > > > > > to do
> > > > > > > > > >> > so.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > > > > > >> > >
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > > So, I agree a space would be helpful.
> > Although
> > > > > it's
> > > > > > > old
> > > > > > > > > >> > > > > > > > school
> > > > > > > > > >> > and
> > > > > > > > > >> > > > > > > > inconvenient, the mailing list is the
> > canonical
> > > > > > place
> > > > > > > > > >> > > > > > > > for
> > > > > > > > > >> > > > discussion.
> > > > > > > > > >> > > > > > > > We currently use GitHub issues a lot, but
> > that's
> > > > > > > copied
> > > > > > > > > >> > > > > > > > to a
> > > > > > > > > >> > > > mailing
> > > > > > > > > >> > > > > > > > list (as is our old JIRA space), so if
> > people
> > > > want
> > > > > > to
> > > > > > > > > >> > participate
> > > > > > > > > >> > > > > > > > without a GitHub account, they can still do
> > > > that.
> > > > > > > There
> > > > > > > > > >> > > > > > > > are
> > > > > > > > > >> > certain
> > > > > > > > > >> > > > > > > > options that are perhaps less convenient,
> > such
> > > > as
> > > > > > just
> > > > > > > > > >> > > > > > > > using
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > > > > mailing list and our dev SVN space, but
> > still
> > > > more
> > > > > > > > > >> > > > > > > > appropriate
> > > > > > > > > >> > than
> > > > > > > > > >> > > > > > > > options that would be less ubiquitous for
> > > > > potential
> > > > > > > > > >> > participants.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > I think the ASF Confluence is probably
> > fine, for
> > > > > > > > > >> > > > > > > > storing,
> > > > > > > > > >> > editing,
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > > > > > > collaborating on shared documents, but
> > decisions
> > > > > > about
> > > > > > > > > >> > > > > > > > those
> > > > > > > > > >> > would
> > > > > > > > > >> > > > > > > > still need to be done on the mailing list.
> > If I
> > > > > > > > > >> > > > > > > > remember
> > > > > > > > > >> > > > correctly, we
> > > > > > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > > > > > >> > > > favor
> > > > > > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > > > > > >> > > > > > > > mis-remembering, but
> > > > > > > > > >> > I
> > > > > > > > > >> > > > think
> > > > > > > > > >> > > > > > > > this is the case. It might explain why you
> > can't
> > > > > > > create
> > > > > > > > > >> > > > > > > > a
> > > > > > > > > >> > > > Confluence
> > > > > > > > > >> > > > > > > > space.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > My preference would be to just use the
> > website.
> > > > I
> > > > > > > think
> > > > > > > > > >> > > > > > > > it's
> > > > > > > > > >> > fine
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > > > > have a dev / design area of the website,
> > and we
> > > > > can
> > > > > > > > > >> > > > > > > > discuss on
> > > > > > > > > >> > > > GitHub
> > > > > > > > > >> > > > > > > > issues for the accumulo-website repo. That
> > is a
> > > > > bit
> > > > > > > > > >> > > > > > > > less
> > > > > > > > > >> > convenient
> > > > > > > > > >> > > > > > > > than Confluence if it's used heavily, but
> > it's
> > > > > more
> > > > > > > > > >> > > > > > > > convenient
> > > > > > > > > >> > in
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > > > sense that it's more accessible and fits
> > more in
> > > > > > line
> > > > > > > > > >> > > > > > > > with our
> > > > > > > > > >> > > > current
> > > > > > > > > >> > > > > > > > mode of operation. Plus, when a document is
> > > > final,
> > > > > > > it's
> > > > > > > > > >> > > > > > > > easy to
> > > > > > > > > >> > > > link
> > > > > > > > > >> > > > > > > > to from our documentation, without making
> > users
> > > > > jump
> > > > > > > to
> > > > > > > > > >> > > > > > > > another service to view docs.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > I would be opposed to using GitHub wiki or
> > a new
> > > > > git
> > > > > > > > repo.
> > > > > > > > > >> > > > > > > > We
> > > > > > > > > >> > have
> > > > > > > > > >> > > > > > > > enough repos. Although it seems like they
> > are
> > > > > free,
> > > > > > > > > >> > > > > > > > there is
> > > > > > > > > >> > still
> > > > > > > > > >> > > > a
> > > > > > > > > >> > > > > > > > lot of boilerplate work to maintain them,
> > from
> > > > > > > managing
> > > > > > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md,
> > > > etc.,
> > > > > to
> > > > > > > > > >> > .asf.yaml, to
> > > > > > > > > >> > > > > > > > README, to keeping copyright dates updated
> > in
> > > > the
> > > > > > > > > >> > > > > > > > NOTICE file,
> > > > > > > > > >> > and
> > > > > > > > > >> > > > > > > > more.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > In summary, my preference:
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > 1. Keep a space in accumulo-website,
> > discuss on
> > > > GH
> > > > > > > > > >> > > > > > > > issues and
> > > > > > > > > >> > > > mailing
> > > > > > > > > >> > > > > > > > list (strongly preferred) 2. Confluence,
> > discuss
> > > > > on
> > > > > > > > > >> > > > > > > > mailing list (prefer over other
> > > > > > > > > >> > options,
> > > > > > > > > >> > > > but
> > > > > > > > > >> > > > > > > > not a fan)
> > > > > > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list
> > > > (strongly
> > > > > > > > > >> > > > > > > > prefer not
> > > > > > > > > >> > to use
> > > > > > > > > >> > > > > > this
> > > > > > > > > >> > > > > > > > option)
> > > > > > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> > > > > mailing
> > > > > > > > > >> > > > > > > > list
> > > > > > > > > >> > (strongly
> > > > > > > > > >> > > > > > > > prefer not to use this option)
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > > > > > >> > edcoleman@apache.org>
> > > > > > > > > >> > > > > > wrote:
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > Currently, asf cannot create new wiki's
> > > > because
> > > > > > of a
> > > > > > > > > >> > Confluence
> > > > > > > > > >> > > > > > issue (
> > > > > > > > > >> > > > > > > >
> > > > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > )
> > > > > > I
> > > > > > > > > >> > > > > > > > chatted
> > > > > > > > > >> > with
> > > > > > > > > >> > > > > > infra
> > > > > > > > > >> > > > > > > > and in response they created that issue.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > To expand on this discussion, I would
> > like to
> > > > > toss
> > > > > > > > > >> > > > > > > > > out
> > > > > > > > > >> > another
> > > > > > > > > >> > > > > > > > alternative to discuss / explore. What if
> > we
> > > > > used a
> > > > > > > > > >> > > > > > > > separate
> > > > > > > > > >> > > > GitHub
> > > > > > > > > >> > > > > > > > project, something like Accumulo-Design,
> > just
> > > > > like
> > > > > > > > > >> > accumulo-proxy
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > > > > > > accumulo-examples. As a separate project,
> > it
> > > > > would
> > > > > > be
> > > > > > > > > >> > available
> > > > > > > > > >> > > > for
> > > > > > > > > >> > > > > > > > collaboration for the community, but remain
> > > > > separate
> > > > > > > > > >> > > > > > > > from main
> > > > > > > > > >> > > > project
> > > > > > > > > >> > > > > > and
> > > > > > > > > >> > > > > > > > the website to keep current code /
> > > > documentation /
> > > > > > > > > >> > > > > > > > design
> > > > > > > > > >> > clearly
> > > > > > > > > >> > > > > > separate
> > > > > > > > > >> > > > > > > > from speculative design discussions. As a
> > > > > project:
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > - document history would be preserved
> > with git
> > > > > > > commit
> > > > > > > > > >> > history.
> > > > > > > > > >> > > > > > > > > - document collaboration could be done
> > with
> > > > > normal
> > > > > > > PR
> > > > > > > > > >> > > > submissions /
> > > > > > > > > >> > > > > > > > reviews.
> > > > > > > > > >> > > > > > > > > - issues could be used to discuss design
> > > > > aspects,
> > > > > > > > > >> > > > > > > > > capturing
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > > comment
> > > > > > > > > >> > > > > > > > history.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > The biggest downside is that it would be
> > yet
> > > > > > another
> > > > > > > > > >> > > > > > > > > project
> > > > > > > > > >> > to
> > > > > > > > > >> > > > > > follow /
> > > > > > > > > >> > > > > > > > track.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > For me, I think the issue is that we need
> > a
> > > > > > public,
> > > > > > > > > >> > collaborative
> > > > > > > > > >> > > > > > space
> > > > > > > > > >> > > > > > > > to hold design discussions. Neither the main
> > > > > project
> > > > > > > or
> > > > > > > > > >> > > > > > > > the
> > > > > > > > > >> > > > web-site
> > > > > > > > > >> > > > > > seem
> > > > > > > > > >> > > > > > > > quite appropriate and Confluence seems to
> > lack
> > > > the
> > > > > > > > > >> > collaboration
> > > > > > > > > >> > > > that
> > > > > > > > > >> > > > > > can
> > > > > > > > > >> > > > > > > > be achieved with github.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > We need a space to capture the redesign
> > and
> > > > > > whatever
> > > > > > > > > >> > > > > > > > > we
> > > > > > > > > >> > select
> > > > > > > > > >> > > > can be
> > > > > > > > > >> > > > > > > > made to work - I'm just wondering what
> > provides
> > > > > the
> > > > > > > > > >> > > > > > > > easiest
> > > > > > > > > >> > forum
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > > build
> > > > > > > > > >> > > > > > > > a collaborative space for the Accumulo
> > > > community.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > Ed Coleman
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > On 2023/02/28 16:35:31
> > dlmarion@comcast.net
> > > > > > wrote:
> > > > > > > > > >> > > > > > > > > > Circling back on this issue - I agree
> > that
> > > > > > > comments
> > > > > > > > > >> > > > > > > > > > and
> > > > > > > > > >> > such
> > > > > > > > > >> > > > make
> > > > > > > > > >> > > > > > > > sense for internal design documents. I'm
> > going
> > > > to
> > > > > > > > > >> > > > > > > > create an
> > > > > > > > > >> > INFRA
> > > > > > > > > >> > > > > > ticket
> > > > > > > > > >> > > > > > > > for a cwiki space for Accumulo unless there
> > are
> > > > > any
> > > > > > > > > >> objections.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > -----Original Message-----
> > > > > > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16
> > PM
> > > > > > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github
> > wiki in
> > > > > > > > asf.yaml?
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > As mentioned, wikis can provide a
> > > > streamlined
> > > > > > > > > >> > > > > > > > > > collaborative
> > > > > > > > > >> > > > editing
> > > > > > > > > >> > > > > > > > workflow that's less labor intensive than
> > > > > updating a
> > > > > > > > > >> website.
> > > > > > > > > >> > They
> > > > > > > > > >> > > > can
> > > > > > > > > >> > > > > > > > promote collaboration by providing specific
> > > > > tooling
> > > > > > to
> > > > > > > > > >> > > > > > > > support
> > > > > > > > > >> > > > > > comments,
> > > > > > > > > >> > > > > > > > revisions and iteration.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > In terms of preservation, GH wikis act
> > just
> > > > > like
> > > > > > > > > >> > > > > > > > > > any other
> > > > > > > > > >> > Git
> > > > > > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > > > > > git@github.com
> > > > > > > > > :
> > > > > > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > > > > > >> > > > > > > > > > IIRC the pages are just GH flavored
> > > > markdown.
> > > > > > > There
> > > > > > > > > >> > > > > > > > > > are at
> > > > > > > > > >> > > > least a
> > > > > > > > > >> > > > > > few
> > > > > > > > > >> > > > > > > > Apache projects using them.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > However, GH wikis lack some features
> > that I
> > > > > feel
> > > > > > > > > >> > > > > > > > > > are
> > > > > > > > > >> > important
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > > > > support collaborative authoring. For
> > example,
> > > > the
> > > > > > > > > >> > > > > > > > ability to
> > > > > > > > > >> > > > comment
> > > > > > > > > >> > > > > > and
> > > > > > > > > >> > > > > > > > discuss specific passages in a document is a
> > > > > feature
> > > > > > > > > >> > > > > > > > that's
> > > > > > > > > >> > > > present in
> > > > > > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come
> > appreciate
> > > > > > this
> > > > > > > > > >> > > > > > > > this in
> > > > > > > > > >> > my
> > > > > > > > > >> > > > google
> > > > > > > > > >> > > > > > > > docs and office workflows, so expect that it
> > > > would
> > > > > > be
> > > > > > > > > >> > > > > > > > useful
> > > > > > > > > >> > for
> > > > > > > > > >> > > > > > Accumulo
> > > > > > > > > >> > > > > > > > design discussions too.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith
> > > > Turner <
> > > > > > > > > >> > > > kturner@apache.org>
> > > > > > > > > >> > > > > > > > wrote:
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > > > > > documents,
> > > > > > > > > >> > > > > > > > > > > I think
> > > > > > > > > >> > it
> > > > > > > > > >> > > > > > would be
> > > > > > > > > >> > > > > > > > > > > less cumbersome than the website and
> > we
> > > > can
> > > > > > > > > >> > > > > > > > > > > always link
> > > > > > > > > >> > from
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > > > > > > website and issues to the wiki. I
> > think
> > > > its
> > > > > > ok
> > > > > > > > > >> > > > > > > > > > > to give
> > > > > > > > > >> > it a
> > > > > > > > > >> > > > try
> > > > > > > > > >> > > > > > and
> > > > > > > > > >> > > > > > > > > > > abandon it in the future, if abandoned
> > > > would
> > > > > > > just
> > > > > > > > > >> > > > > > > > > > > need to
> > > > > > > > > >> > > > > > properly
> > > > > > > > > >> > > > > > > > > > > communicate that. The content should
> > be
> > > > > > > archived
> > > > > > > > > >> > > > > > > > > > > in
> > > > > > > > > >> > Apache
> > > > > > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does
> > not do
> > > > > that
> > > > > > > > > >> > > > > > > > > > > then we
> > > > > > > > > >> > should
> > > > > > > > > >> > > > > > not use
> > > > > > > > > >> > > > > > > > > > > it. If GH wiki is not an option then
> > > > could
> > > > > > try
> > > > > > > > > cwiki.
> > > > > > > > > >> > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I reverted the change. I didn't
> > think it
> > > > > > would
> > > > > > > > > >> > > > > > > > > > > > be a big
> > > > > > > > > >> > > > deal,
> > > > > > > > > >> > > > > > but
> > > > > > > > > >> > > > > > > > if
> > > > > > > > > >> > > > > > > > > > > > it
> > > > > > > > > >> > > > > > > > > > > requires discussion, then let's
> > discuss
> > > > it.
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I'm looking for a place to host
> > > > > information
> > > > > > > > > >> > > > > > > > > > > > related to
> > > > > > > > > >> > > > internal
> > > > > > > > > >> > > > > > > > > > > > design
> > > > > > > > > >> > > > > > > > > > > discussions. I envision these to be
> > living
> > > > > > > > > >> > > > > > > > > > > documents that
> > > > > > > > > >> > > > will be
> > > > > > > > > >> > > > > > > > > > > updated over time as the
> > > > > design/implementation
> > > > > > > > > >> > progresses and
> > > > > > > > > >> > > > > > that
> > > > > > > > > >> > > > > > > > > > > other committers will be able to
> > comment
> > > > on
> > > > > > and
> > > > > > > > > >> > > > > > > > > > > edit. I
> > > > > > > > > >> > don't
> > > > > > > > > >> > > > > > feel
> > > > > > > > > >> > > > > > > > > > > that the website is the correct place
> > for
> > > > > this
> > > > > > > > > >> because:
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > > > > > discussions
> > > > > > > > > >> > > > > > > > > > > > should
> > > > > > > > > >> > go
> > > > > > > > > >> > > > on the
> > > > > > > > > >> > > > > > > > > > > > project
> > > > > > > > > >> > > > > > > > > > > website.
> > > > > > > > > >> > > > > > > > > > > > 2. Changes to the design documents
> > > > could
> > > > > > not
> > > > > > > > > >> > > > > > > > > > > > be seen
> > > > > > > > > >> > by
> > > > > > > > > >> > > > > > others
> > > > > > > > > >> > > > > > > > > > > > right
> > > > > > > > > >> > > > > > > > > > > away (IIRC changes to the website are
> > > > built
> > > > > > and
> > > > > > > > > >> > available at
> > > > > > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/,
> > but
> > > > > > human
> > > > > > > > > >> > intervention
> > > > > > > > > >> > > > is
> > > > > > > > > >> > > > > > > > > > > required to publish it at
> > > > > > > > > >> https://accumulo.apache.org/).
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I looked in the INFRA issues and
> > other
> > > > > > > projects
> > > > > > > > > >> > > > > > > > > > > > are
> > > > > > > > > >> > using
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > GH
> > > > > > > > > >> > > > > > > > > > > > Wiki
> > > > > > > > > >> > > > > > > > > > > feature and I saw no mention of
> > backing it
> > > > > up
> > > > > > or
> > > > > > > > > >> > > > > > > > > > > the
> > > > > > > > > >> > > > requirement
> > > > > > > > > >> > > > > > to
> > > > > > > > > >> > > > > > > > do
> > > > > > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing
> > it
> > > > > up?).
> > > > > > > It
> > > > > > > > > >> > > > > > > > > > > does
> > > > > > > > > >> > appear
> > > > > > > > > >> > > > > > that we
> > > > > > > > > >> > > > > > > > > > > would need an INFRA ticket so that
> > they
> > > > can
> > > > > > > > > >> > > > > > > > > > > modify the
> > > > > > > > > >> > GitHub
> > > > > > > > > >> > > > > > project
> > > > > > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down
> > so
> > > > > that
> > > > > > > > > >> > > > > > > > > > > only
> > > > > > > > > >> > > > committers can
> > > > > > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not
> > > > acceptable,
> > > > > > > then
> > > > > > > > > >> > > > > > > > > > > I think
> > > > > > > > > >> > > > Apache
> > > > > > > > > >> > > > > > > > > > > Confluence (
> > > > > > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > > > > > acceptable
> > > > > > > > > >> > > > alternative.
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > >> > > > > > > > > > > > From: Christopher <
> > ctubbsii@apache.org>
> > > > > > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023
> > 4:41
> > > > AM
> > > > > > > > > >> > > > > > > > > > > > To: accumulo-dev <
> > > > dev@accumulo.apache.org
> > > > > >
> > > > > > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> > > > > updated:
> > > > > > > > > >> > > > > > > > > > > > Enable
> > > > > > > > > >> > Github
> > > > > > > > > >> > > > > > wiki in
> > > > > > > > > >> > > > > > > > > > > asf.yaml
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I don't recall a discussion about
> > this
> > > > > > change,
> > > > > > > > > >> > > > > > > > > > > > but I
> > > > > > > > > >> > think
> > > > > > > > > >> > > > it
> > > > > > > > > >> > > > > > goes
> > > > > > > > > >> > > > > > > > > > > against previous efforts to make the
> > > > website
> > > > > > the
> > > > > > > > > >> > > > > > > > > > > one
> > > > > > > > > >> > > > canonical
> > > > > > > > > >> > > > > > > > > > > location for our documentation. I
> > don't
> > > > even
> > > > > > > > > >> > > > > > > > > > > think infra
> > > > > > > > > >> > is
> > > > > > > > > >> > > > > > backing
> > > > > > > > > >> > > > > > > > up
> > > > > > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be
> > a
> > > > > record
> > > > > > > of
> > > > > > > > > >> > > > > > > > > > > the
> > > > > > > > > >> > wiki
> > > > > > > > > >> > > > > > contents
> > > > > > > > > >> > > > > > > > in
> > > > > > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which
> > is
> > > > > backed
> > > > > > > up
> > > > > > > > > >> > > > > > > > > > > to
> > > > > > > > > >> > GitBox
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > > > > > > > > > > issue tracker, which CCs the
> > notifications
> > > > > > > list).
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > In short, I think this should be
> > > > reverted
> > > > > > and
> > > > > > > > > >> > > > > > > > > > > > we
> > > > > > > > > >> > should not
> > > > > > > > > >> > > > > > use the
> > > > > > > > > >> > > > > > > > > > > GitHub wiki. If we need to store
> > documents
> > > > > in
> > > > > > a
> > > > > > > > > >> > > > > > > > > > > version
> > > > > > > > > >> > > > > > controlled
> > > > > > > > > >> > > > > > > > > > > way, we can store them on the
> > website, or
> > > > in
> > > > > > our
> > > > > > > > > >> > project's
> > > > > > > > > >> > > > SVN
> > > > > > > > > >> > > > > > dev
> > > > > > > > > >> > > > > > > > > > > space. The wiki is just another place
> > > > people
> > > > > > > > > >> > > > > > > > > > > would have
> > > > > > > > > >> > to
> > > > > > > > > >> > > > > > follow if
> > > > > > > > > >> > > > > > > > > > > they want to participate, and I don't
> > > > think
> > > > > > that
> > > > > > > > > >> > > > > > > > > > > serves
> > > > > > > > > >> > us.
> > > > > > > > > >> > > > > > > > Therefore,
> > > > > > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > This is an automated email from
> > the
> > > > ASF
> > > > > > > > > >> > > > > > > > > > > > > dual-hosted
> > > > > > > > > >> > git
> > > > > > > > > >> > > > > > > > repository.
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch
> > > > main
> > > > > in
> > > > > > > > > >> > > > > > > > > > > > > repository
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > > > > > >> > > > > > > > > > > > > git
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > The following commit(s) were
> > added to
> > > > > > > > > >> > refs/heads/main by
> > > > > > > > > >> > > > this
> > > > > > > > > >> > > > > > > > push:
> > > > > > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github
> > wiki
> > > > > in
> > > > > > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > > > > > >> > > > > > ae8a817e7b is
> > > > > > > > > >> > > > > > > > > > > > > described below
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > commit
> > > > > > > > > >> > > > > > > > > > > > >
> > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> > > > > dlmarion@apache.org>
> > > > > > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10
> > 2023
> > > > > -0500
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > >> > > > > > > > > > > > > ---
> > > > > > > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml
> > > > index
> > > > > > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > > > > > >> > > > > > > > > > > > > 100644
> > > > > > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > >> > > > > > > > > > > > > - big-data
> > > > > > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > > > > > >> > > > > > > > > > > > > features:
> > > > > > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > > > > > >> > > > > > > > > > > > > issues: true
> > > > > > > > > >> > > > > > > > > > > > > projects: true
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
Those aren't differences (either not a difference at all, or not a
meaningful one).
1. Immediate availability. GitHub already renders the content
immediately... this is why we can view Markdown files like README and
other file types directly in the repo navigation. The non-immediate
view on the website is a secondary view... but even that takes mere
seconds to build and render.
2. Not publishing draft/WIP design documents on the website: whether
we have the rendered files accessible at
confluence.apache.org/accumulo/designs or accumulo.apache.org/designs,
we're still publishing to the exact same extent. The files are being
made publicly available to developers / potential contributors, but
not promoted to users in draft form. It's the same thing. Presumably,
in our developer docs, we would link to the confluence/GitHub wiki so
other devs can find it. This is the same as linking to our
accumulo-website repo or to the /designs folder on our website. The
only difference that matters for publication is whether we make it
available to developers or if we promote it to users. But, linking to
one site for developers vs. another site for developers is not a
difference in any way that is meaningful.
Again, I will point to an existing precedent for precisely the same
thing (working document for a feature design) at
https://github.com/apache/accumulo-website/blob/main/design/system-snapshot.md
; This was added using a PR
https://github.com/apache/accumulo-website/pull/163 with
comments/discussion that triggered notifications to our mailing lists
for participation opportunity, was rendered in Markdown immediately,
and ultimately got merged to a folder that does not have a link
anywhere on the website, so we don't promote it in draft form to
users. The workflow followed for that hits *all* of the stated
requirements, is an existing precedent, was quite convenient, *and*
has the added benefit of being consolidated in the same repo as other
docs. It also is mirrored to ASF's gitbox and would have notifications
triggered to the mailing list for any non-GitHub users, so it doesn't
require any separate accounts like Confluence or GitHub to
participate. It also matches our existing collaboration workflow,
which I think is important for a small project like ours, so we don't
spread ourselves too thin.
As for the downsides of putting the Wiki in a subfolder in the project:
1. The .asf.yaml doesn't seem to support configuring it to be based on
a subfolder, so this would require getting INFRA involved for
changes... which I'd rather not do. I'd rather do things that are
self-serve as much as possible. I did briefly look into this, and I
also can't find GitHub documentation for how to put a wiki in a
subfolder. I found the docs for putting the GitHub Pages website in a
subfolder, but that's different, and not what anybody has proposed.
2. It would have to be put in a separate repo, rather than the main
accumulo repo, because putting it in the main repo would mean we'd
have to work around it for the build environment (it would also
undermine the whole effort to strip the docs/ directory out of the
main repo). If we put it in an existing repo, then the best candidate
would be the accumulo-website repo anyway, and we'd have to either
ignore that directory during the website build, or it would end up on
the website anyway... which is what I proposed, but with the extra
complexity of having a separate wiki feature tied to it.
I'm not saying the website repo as I've proposed is a 100% perfect
solution... but I think of all the options, it's the best for the
project long term. I don't think we need a specialty product or
tailored platform to get what we want. I know people have their own
preferences... but on the technical merits, I still think this is the
best option.
On Thu, Mar 16, 2023 at 8:23 AM Dave Marion <dm...@gmail.com> wrote:
>
> This was just something I found to answer the issue of notifications,
> issues, and PRs. I think the main difference is that it's immediately
> available on the GitHub site for viewing vs having to wait for it to be
> published to the website and that we're not publishing draft or WIP design
> documents to the website. I still think that Confluence is a better option
> regarding comments and discussion, hopefully infra can figure that out.
>
> On Thu, Mar 16, 2023 at 7:51 AM Christopher <ct...@apache.org> wrote:
>
> > Isn't that basically the same as how the website repo works? How would
> > that be different then?
> >
> > On Wed, Mar 15, 2023 at 2:55 PM Dave Marion <dm...@gmail.com> wrote:
> > >
> > > It looks like we could generate the GH wiki from a folder in the source
> > > code. This would allow for issues and PRs. Just a thought.
> > >
> > > Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
> > >
> > https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
> > >
> > > On Wed, Mar 15, 2023 at 2:16 PM Christopher <ct...@apache.org> wrote:
> > >
> > > > It seems like there's a majority consensus of those engaged. No need
> > for a
> > > > vote, but I think the question about notifications should be addressed
> > > > first.
> > > >
> > > > On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
> > > > christopher.l.shannon@gmail.com> wrote:
> > > >
> > > > > I'm +1 to using some kind of wiki so if we can't use Confluence then
> > GH
> > > > > sounds fine to me. Do we need to take a formal vote for using the
> > Github
> > > > > wiki or is there enough consensus already?
> > > > >
> > > > > On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > +1 for the GH wiki with major discussions still being fed into, or
> > > > > > originated on the mailing lists.
> > > > > >
> > > > > > As a side question, if there is a lengthy discussion on a GH
> > issue, is
> > > > it
> > > > > > standard practice to just recap that in a mailing list message?
> > > > > > Or is there a more "formal" inclusion process to follow?
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > I don't think the workflow I proposed about using PRs and
> > discussion
> > > > on
> > > > > > > tickets, etc. and the accompanying arguments about keeping things
> > > > > > > consolidated and accessible to potential contributors not
> > > > participating
> > > > > > on
> > > > > > > GitHub, were really challenged at all. However, since I seem to
> > be
> > > > the
> > > > > > only
> > > > > > > one advocating for using the website, to keep things
> > centralized, as
> > > > > per
> > > > > > > previous attempts to consolidate documentation, I won't fight
> > the use
> > > > > of
> > > > > > > GitHub wiki. But I do want to make it clear that we're
> > proceeding in
> > > > > that
> > > > > > > direction under my objection (-0), and that I'm not convinced
> > this is
> > > > > the
> > > > > > > best path forward. Hopefully, I will be proven wrong in time.
> > > > > > >
> > > > > > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com>
> > wrote:
> > > > > > >
> > > > > > > > > At this point, I think we should move forward with a GH wiki
> > and
> > > > > then
> > > > > > > we
> > > > > > > > can re-evaluate things once the Apache confluence issue is
> > sorted
> > > > > out.
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com>
> > wrote:
> > > > > > > >
> > > > > > > > > I just tried (Wed, 3/15) and still received the same error.
> > I
> > > > > asked
> > > > > > on
> > > > > > > > > the infra slack channel and they replied that they are still
> > > > > working
> > > > > > to
> > > > > > > > > determine what the issue is - signs are pointing to something
> > > > > inside
> > > > > > of
> > > > > > > > > confluence, but no progress.
> > > > > > > > >
> > > > > > > > > At this point, I think we should move forward with a GH wiki
> > and
> > > > > then
> > > > > > > we
> > > > > > > > > can re-evaluate things once the Apache confluence issue is
> > sorted
> > > > > > out.
> > > > > > > > >
> > > > > > > > > Ed Coleman
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Dave Marion <dm...@gmail.com>
> > > > > > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > >
> > > > > > > > > Looking at the Infra slack channel response, one of the
> > responses
> > > > > in
> > > > > > > the
> > > > > > > > > channel said that "it's some sort of db corruption according
> > to
> > > > > > > > Atlassian".
> > > > > > > > > Doesn't sound good....
> > > > > > > > >
> > > > > > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <
> > dmarion18@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > > > > > unresolved
> > > > > > > > > > and the only comment on the ticket is one that Ed added two
> > > > days
> > > > > > ago
> > > > > > > > > > requesting an ACCUMULO wiki space.
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com>
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> I do not see any comments in the infa slack channel - so
> > no
> > > > > > updates
> > > > > > > > > >> for now.
> > > > > > > > > >>
> > > > > > > > > >> -----Original Message-----
> > > > > > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > > > > > >> To: dev@accumulo.apache.org
> > > > > > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > > >>
> > > > > > > > > >> Right, I was just curious if there was any follow-up as I
> > > > think
> > > > > Ed
> > > > > > > > > >> said that it was going to be discussed by the INFRA team
> > > > > > yesterday.
> > > > > > > > > >> There is at least one other recent ticket (
> > > > > > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > > > > > selfserve
> > > > > > > > > >> had an issue and the INFRA team created the space
> > manually.
> > > > > > > > > >>
> > > > > > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> > > > > ctubbsii@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >> > You can track that issue at
> > > > > > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > > > > > >> >
> > > > > > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > > > > > dmarion18@gmail.com>
> > > > > > > > > >> wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > Ed,
> > > > > > > > > >> > >
> > > > > > > > > >> > > Any update from INFRA on being able to create
> > confluence
> > > > > > > pages?
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > > > > > ctubbsii@apache.org
> > > > > > > >
> > > > > > > > > >> wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > > We've definitely used the website for more than
> > that. We
> > > > > use
> > > > > > > it
> > > > > > > > > >> > > > to document things for users, help developers know
> > how
> > > > to
> > > > > > > > > >> > > > contribute, store drafts of designs, share user
> > stories
> > > > > via
> > > > > > > > > >> > > > blogs, do release announcements, and more. There's
> > > > > > definitely
> > > > > > > > > >> > > > space on the website to do this kind of thing, if we
> > > > want
> > > > > > to.
> > > > > > > > > >> > > > We've used it that way before. If you only see it
> > as a
> > > > > place
> > > > > > > > > >> > > > "for user consumption after everything has been
> > > > > finalized",
> > > > > > > > > >> > > > then you're missing out on the other ways we
> > currently
> > > > use
> > > > > > the
> > > > > > > > > >> > > > site, and the ways we've used it in
> > > > > > > > > >> the past.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > With the website, most of the collaboration would
> > happen
> > > > > in
> > > > > > > the
> > > > > > > > > >> > > > GH issues about proposed designs or changes to
> > designs,
> > > > > just
> > > > > > > > > >> > > > like we do today with code or other documentation,
> > which
> > > > > > > > > >> > > > everybody is used to. I agree it's not as good as
> > Google
> > > > > > Docs
> > > > > > > > > >> > > > for on-the-fly comments/annotations, but I don't
> > think
> > > > > > > > > >> > > > Confluence or Wiki are as good as that either, and
> > > > Google
> > > > > > Docs
> > > > > > > > > isn't really an option...
> > > > > > > > > >> > > > unless you just want to link to it in the mailing
> > list
> > > > and
> > > > > > > > > >> > > > stick to Google Docs from your personal Google
> > account,
> > > > > > until
> > > > > > > > > >> > > > it's ready for publication, which would also be fine
> > > > (any
> > > > > > > > > >> > > > interested persons can simply request write access
> > by
> > > > > > replying
> > > > > > > > > >> > > > to the message where
> > > > > > > > > >> you shared the link)..
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > We are a much smaller project than many others, and
> > we
> > > > > have
> > > > > > > > > >> > > > previously suffered from having stuff too spread
> > out.
> > > > Even
> > > > > > if
> > > > > > > > > >> > > > other projects find a separate space valuable for
> > them,
> > > > > I'm
> > > > > > > not
> > > > > > > > > >> > > > sure it's best for the Accumulo project. While I
> > think
> > > > > it's
> > > > > > > > > >> > > > useful to examine what other projects do, I do
> > think we
> > > > > > should
> > > > > > > > > >> > > > be careful to adopt anything just because others
> > find it
> > > > > > > > > convenient for them.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Confluence is my second choice, but with a big gap
> > > > between
> > > > > > it
> > > > > > > > > >> > > > and my first choice.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > On a personal note: I hate using Confluence,
> > because I
> > > > > think
> > > > > > > > > >> > > > the navigation is highly unintuitive, as is the
> > > > > permissions
> > > > > > > > > >> > > > model, and I don't like the idea of learning yet
> > another
> > > > > > > > > >> > > > wiki-syntax (though I've read Confluence supports
> > some
> > > > > > limited
> > > > > > > > > >> > > > Markdown, but probably not the same as
> > GitHub/Jekyll). I
> > > > > > also
> > > > > > > > > >> > > > do not want to set up custom notifications for
> > watching
> > > > > yet
> > > > > > > > > >> > > > another space. If we use Confluence, I will probably
> > > > > > > contribute
> > > > > > > > > >> > > > very infrequently there because of my frustrations
> > with
> > > > > > having
> > > > > > > > > >> > > > used it before. However, that would be my choice,
> > and
> > > > > should
> > > > > > > > > >> > > > not be a reason the project chooses one over
> > another.
> > > > I'm
> > > > > > > > > >> > > > sharing my personal opinion only because it is
> > > > influencing
> > > > > > my
> > > > > > > > > >> > > > opinion about the website being more accessible,
> > via our
> > > > > > > > > >> > > > current GitHub PR/issue/Markdown workflows, and I
> > wonder
> > > > > how
> > > > > > > > > >> > > > many other potential contributors would feel
> > similarly.
> > > > > It's
> > > > > > > > > >> > > > hard to know, since it seems like a lot of this is
> > > > > > subjective,
> > > > > > > > > >> > > > and is going to come down to a consensus of personal
> > > > > > > > > >> preferences.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > > > > > >> > > > <dm...@gmail.com>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > I don't see the website as an area where we would
> > have
> > > > > > > > > >> > > > > collaborative discussions about an idea. For
> > example,
> > > > > > making
> > > > > > > > > >> > > > > comments and
> > > > > > > > > >> > suggestions
> > > > > > > > > >> > > > on
> > > > > > > > > >> > > > > a document like you can do in Google Docs. I see
> > the
> > > > > > website
> > > > > > > > > >> > > > > as a
> > > > > > > > > >> > place
> > > > > > > > > >> > > > > where items are documented for user consumption
> > after
> > > > > > > > > >> > > > > everything has
> > > > > > > > > >> > been
> > > > > > > > > >> > > > > finalized. I'm not trying to create a private
> > > > discussion
> > > > > > > > > >> > > > > area, I
> > > > > > > > > >> > think
> > > > > > > > > >> > > > > anyone can see the wiki (but I think anonymous
> > > > comments
> > > > > > are
> > > > > > > > > >> > > > > disabled
> > > > > > > > > >> > due
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > spam issues). I see no issue with putting
> > > > > work-in-progress
> > > > > > > > > >> > > > > documents
> > > > > > > > > >> > on a
> > > > > > > > > >> > > > > wiki and referencing them via emails to the dev
> > list.
> > > > I
> > > > > > > think
> > > > > > > > > >> > > > > this is
> > > > > > > > > >> > > > done
> > > > > > > > > >> > > > > in a lot of other projects. Non-committers that
> > don't
> > > > > have
> > > > > > > > > >> > > > > access to
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > wiki and want to make comments, suggestions, and
> > ask
> > > > > > > > > >> > > > > questions can
> > > > > > > > > >> > do so
> > > > > > > > > >> > > > > via the mailing list. I think it's also possible
> > that
> > > > > > people
> > > > > > > > > >> > > > > can get confluence accounts (see
> > > > > > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > > > > > >> > > > > so if a non-committer wanted to participate they
> > > > could.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > > > > > >> > > > > <ct...@apache.org>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > > > > > >> > > > > > <dm...@gmail.com>
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > I'm opposed to using the website for the
> > reasons I
> > > > > > > > > >> > > > > > > specified
> > > > > > > > > >> > > > earlier, so
> > > > > > > > > >> > > > > > it
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Your reasons that I saw were:
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > 1. I don't think internal design discussions
> > > > should
> > > > > go
> > > > > > > on
> > > > > > > > > >> > > > > > > the
> > > > > > > > > >> > project
> > > > > > > > > >> > > > > > website.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > That doesn't look to me like a reason. That
> > appears
> > > > to
> > > > > > > just
> > > > > > > > > >> > > > > > be
> > > > > > > > > >> > stating
> > > > > > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > 2. Changes to the design documents could not
> > be
> > > > seen
> > > > > > by
> > > > > > > > > >> > > > > > > others
> > > > > > > > > >> > right
> > > > > > > > > >> > > > > > away (IIRC changes to the website are built and
> > > > > > available
> > > > > > > > > >> > > > > > at https://accumulo.staged.apache.org/, but
> > human
> > > > > > > > > >> > > > > > intervention is
> > > > > > > > > >> > > > required
> > > > > > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > What do you mean by "others" here? Do you mean
> > > > > "users",
> > > > > > as
> > > > > > > > > >> > > > > > opposed
> > > > > > > > > >> > to
> > > > > > > > > >> > > > > > "developers/contributors"? The ASF draws a
> > > > distinction
> > > > > > > > > >> > > > > > between "developers/contributors" and "users"
> > as it
> > > > > > > > > >> > > > > > pertains to official releases. Releases are
> > intended
> > > > > to
> > > > > > be
> > > > > > > > > >> > > > > > consumed by users, and pre-release stuff is
> > intended
> > > > > to
> > > > > > be
> > > > > > > > > >> > > > > > collaborative, open to all potential
> > > > > > > > > >> > > > > > developers/contributors. Very very rarely are
> > things
> > > > > > > > > >> > > > > > reserved exclusively for committers. We don't
> > even
> > > > > have
> > > > > > a
> > > > > > > > > >> > > > > > private committers space (the private mailing
> > list
> > > > is
> > > > > > > > > >> > > > > > PMC-private, not committer-private). Having a
> > > > > > distinction
> > > > > > > > > >> > > > > > between users and
> > > > > > > > > >> > developers
> > > > > > > > > >> > > > > > doesn't mean we can't publish things on the
> > > > website...
> > > > > > it
> > > > > > > > > >> > > > > > just
> > > > > > > > > >> > means
> > > > > > > > > >> > > > > > that we should be careful about how we do it,
> > which
> > > > is
> > > > > > the
> > > > > > > > > >> > > > > > same
> > > > > > > > > >> > care
> > > > > > > > > >> > > > > > we should take regardless of where we put it.
> > > > > > > Specifically,
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > care
> > > > > > > > > >> > > > > > we need to take is to avoid marketing
> > pre-release
> > > > > > content
> > > > > > > > > >> > > > > > to
> > > > > > > > > >> users.
> > > > > > > > > >> > > > > > One way we can exercise this care for content
> > on our
> > > > > > > > > >> > > > > > website is
> > > > > > > > > >> > that
> > > > > > > > > >> > > > > > we can avoid sharing these unpolished designs by
> > > > > simply
> > > > > > > not
> > > > > > > > > >> > > > > > linking them on the site, or by placing them in
> > an
> > > > > area
> > > > > > > > > >> > > > > > that is clearly
> > > > > > > > > >> > marked
> > > > > > > > > >> > > > > > as intended for devs. But, we have no similar
> > > > > > distinction
> > > > > > > > > >> > > > > > between committers and non-committer devs for
> > which
> > > > we
> > > > > > > > > >> > > > > > should avoid sharing pre-release content under
> > > > > > > development.
> > > > > > > > > >> > > > > > In fact, it is the
> > > > > > > > > >> > opposite...
> > > > > > > > > >> > > > > > we should be developing openly so as to allow
> > room
> > > > for
> > > > > > > > > >> > non-committers
> > > > > > > > > >> > > > > > to become committers through participation in
> > > > > > development
> > > > > > > > > >> > activities.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > As for the staging/publication of the website,
> > > > that's
> > > > > > just
> > > > > > > > > >> > > > > > a
> > > > > > > > > >> > mechanic
> > > > > > > > > >> > > > > > for verifying the website isn't broken before we
> > > > serve
> > > > > > it.
> > > > > > > > > >> > > > > > It's
> > > > > > > > > >> > not a
> > > > > > > > > >> > > > > > mechanism for keeping things internal vs.
> > shared and
> > > > > > > > > >> > > > > > doesn't have anything to do with the separation
> > > > > between
> > > > > > > > > >> > > > > > devs and users. We
> > > > > > > > > >> > already
> > > > > > > > > >> > > > > > publish Draft contents to the website, as well
> > as
> > > > > > > > > >> > developer-specific
> > > > > > > > > >> > > > > > documentation not intended for users.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > We've even specifically published
> > work-in-progress
> > > > > > design
> > > > > > > > > >> > > > > > documents there, of the same type that seems to
> > be
> > > > the
> > > > > > > > > >> > > > > > basis of this conversation (
> > > > > > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > > > > > >> > I
> > > > > > > > > >> > > > > > would strongly prefer us to continue to do it
> > this
> > > > > way,
> > > > > > > > > >> > > > > > rather than create a new space, and have these
> > kinds
> > > > > of
> > > > > > > > > >> > > > > > things scattered in multiple places.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > If, on the other hand, you intend to say that
> > these
> > > > > > should
> > > > > > > > > >> > > > > > be
> > > > > > > > > >> > private
> > > > > > > > > >> > > > > > because they aren't ready for other potential
> > > > > > > contributors,
> > > > > > > > > >> > > > > > then I would argue that we're an openly
> > developed
> > > > > > > project...
> > > > > > > > > >> > > > > > if something isn't ready to be shared with other
> > > > > > potential
> > > > > > > > > >> > > > > > contributors / developers, such that you want to
> > > > keep
> > > > > it
> > > > > > > > > >> > > > > > internal to existing committers, then it's not
> > ready
> > > > > to
> > > > > > be
> > > > > > > > > >> > > > > > contributed to the project at all... because we
> > > > don't
> > > > > > > > > >> > > > > > restrict collaboration to only existing
> > committers.
> > > > > That
> > > > > > > > > >> > > > > > would prevent others from participating and
> > > > > > > > > >> > earning
> > > > > > > > > >> > > > > > the merit to become committers, and that's not
> > > > > something
> > > > > > > we
> > > > > > > > > >> > > > > > should
> > > > > > > > > >> > be
> > > > > > > > > >> > > > > > doing. Anything that is okay to share with
> > existing
> > > > > > > > > >> > > > > > committers
> > > > > > > > > >> > should
> > > > > > > > > >> > > > > > be okay to share to other potential
> > contributors who
> > > > > > want
> > > > > > > > > >> > > > > > to participate, and should be done in a space
> > that
> > > > > > allows
> > > > > > > > > >> > > > > > them to do that. The website is a perfect space
> > for
> > > > > > that,
> > > > > > > > > >> > > > > > and has everything
> > > > > > > > > >> > we
> > > > > > > > > >> > > > > > need. I'm actually not sure about Confluence...
> > I
> > > > > > suspect
> > > > > > > > > >> > > > > > non-committers wouldn't be able to participate
> > there
> > > > > > > > > >> > > > > > because they probably can't get accounts for it.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > looks like we need to
> > > > > > > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be
> > curious
> > > > how
> > > > > > > much
> > > > > > > > > >> > > > > > > we
> > > > > > > > > >> > need to
> > > > > > > > > >> > > > use
> > > > > > > > > >> > > > > > > the mailing list during
> > > > > > > > > >> > > > > > > the design phase. We can announce meeting
> > > > > dates/times
> > > > > > on
> > > > > > > > > >> > > > > > > the
> > > > > > > > > >> > mailing
> > > > > > > > > >> > > > list
> > > > > > > > > >> > > > > > > and post links to
> > > > > > > > > >> > > > > > > meeting notes in Confluence. Ultimately,
> > decisions
> > > > > > made
> > > > > > > > > >> > > > > > > by the
> > > > > > > > > >> > people
> > > > > > > > > >> > > > > > that
> > > > > > > > > >> > > > > > > want to be involved
> > > > > > > > > >> > > > > > > will turn into pull requests against the
> > codebase
> > > > > > which
> > > > > > > > > >> > comitters can
> > > > > > > > > >> > > > > > weigh
> > > > > > > > > >> > > > > > > in on. When you say,
> > > > > > > > > >> > > > > > > "... but decisions about those would still
> > need to
> > > > > be
> > > > > > > > > >> > > > > > > done on the
> > > > > > > > > >> > > > mailing
> > > > > > > > > >> > > > > > > list." Are you saying that we need to discuss
> > > > every
> > > > > > > > > >> > > > > > > single design decision on the mailing
> > > > > > > > > >> > list?
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Yes and no. I am saying that decisions need to
> > > > happen
> > > > > on
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > mailing
> > > > > > > > > >> > > > > > list, but I agree with you that this can be
> > > > satisfied
> > > > > > > > > >> > > > > > through pull requests. I just wanted to
> > emphasize
> > > > that
> > > > > > > > > >> > > > > > regardless of where we do that pre-decision
> > > > > > collaboration,
> > > > > > > > > >> > > > > > that collaboration should not be misconstrued
> > as a
> > > > > > > decision
> > > > > > > > > >> > > > > > to
> > > > > > > > > >> accept those ideas into the project.
> > > > > > > > > >> > The
> > > > > > > > > >> > > > > > decision occurs during the PR or other activity
> > that
> > > > > > > > > >> > > > > > interfaces
> > > > > > > > > >> > with
> > > > > > > > > >> > > > > > the mailing list, subsequent to the
> > collaboration in
> > > > > the
> > > > > > > > > >> > design/idea
> > > > > > > > > >> > > > > > phase.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > As for the pre-decision collaboration space
> > we're
> > > > > > > > > >> > > > > > discussing, I
> > > > > > > > > >> > just
> > > > > > > > > >> > > > > > want to be careful that we're not creating such
> > a
> > > > > space
> > > > > > in
> > > > > > > > > >> > > > > > an exclusionary way that allows only existing
> > > > > committers
> > > > > > > to
> > > > > > > > > >> > participate,
> > > > > > > > > >> > > > > > that excludes other potential contributors.
> > This is
> > > > > > still
> > > > > > > > > >> > > > > > an openly-developed project, and we should
> > > > collaborate
> > > > > > in
> > > > > > > a
> > > > > > > > > >> > > > > > space
> > > > > > > > > >> > that is
> > > > > > > > > >> > > > > > not exclusive to existing committers, but open
> > to
> > > > > > > > > >> > > > > > non-committer contributors and potential
> > > > contributors
> > > > > as
> > > > > > > > well.
> > > > > > > > > >> > > > > > So, while we may
> > > > > > > > > >> > want
> > > > > > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > > > > > >> > > > > > consumption (an important separation that
> > relates to
> > > > > > > > > >> > > > > > official ASF releases), we
> > > > > > > > > >> > should
> > > > > > > > > >> > > > > > not be drawing a line between committer-devs as
> > > > > > "internal"
> > > > > > > > > >> > > > > > and contributor-devs as "external". The website,
> > > > with
> > > > > > its
> > > > > > > > > >> > > > > > own issue tracker, the ability to render
> > markdown,
> > > > do
> > > > > > > > > >> > > > > > reviews, and collaboratively edit, seems like
> > the
> > > > > ideal
> > > > > > > > > >> > > > > > place to me. We've used
> > > > > > > > > >> > it
> > > > > > > > > >> > > > > > before for the same purpose, and I think we
> > should
> > > > > > > continue
> > > > > > > > > >> > > > > > to do
> > > > > > > > > >> > so.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > > > > > >> > >
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > > So, I agree a space would be helpful.
> > Although
> > > > > it's
> > > > > > > old
> > > > > > > > > >> > > > > > > > school
> > > > > > > > > >> > and
> > > > > > > > > >> > > > > > > > inconvenient, the mailing list is the
> > canonical
> > > > > > place
> > > > > > > > > >> > > > > > > > for
> > > > > > > > > >> > > > discussion.
> > > > > > > > > >> > > > > > > > We currently use GitHub issues a lot, but
> > that's
> > > > > > > copied
> > > > > > > > > >> > > > > > > > to a
> > > > > > > > > >> > > > mailing
> > > > > > > > > >> > > > > > > > list (as is our old JIRA space), so if
> > people
> > > > want
> > > > > > to
> > > > > > > > > >> > participate
> > > > > > > > > >> > > > > > > > without a GitHub account, they can still do
> > > > that.
> > > > > > > There
> > > > > > > > > >> > > > > > > > are
> > > > > > > > > >> > certain
> > > > > > > > > >> > > > > > > > options that are perhaps less convenient,
> > such
> > > > as
> > > > > > just
> > > > > > > > > >> > > > > > > > using
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > > > > mailing list and our dev SVN space, but
> > still
> > > > more
> > > > > > > > > >> > > > > > > > appropriate
> > > > > > > > > >> > than
> > > > > > > > > >> > > > > > > > options that would be less ubiquitous for
> > > > > potential
> > > > > > > > > >> > participants.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > I think the ASF Confluence is probably
> > fine, for
> > > > > > > > > >> > > > > > > > storing,
> > > > > > > > > >> > editing,
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > > > > > > collaborating on shared documents, but
> > decisions
> > > > > > about
> > > > > > > > > >> > > > > > > > those
> > > > > > > > > >> > would
> > > > > > > > > >> > > > > > > > still need to be done on the mailing list.
> > If I
> > > > > > > > > >> > > > > > > > remember
> > > > > > > > > >> > > > correctly, we
> > > > > > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > > > > > >> > > > favor
> > > > > > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > > > > > >> > > > > > > > mis-remembering, but
> > > > > > > > > >> > I
> > > > > > > > > >> > > > think
> > > > > > > > > >> > > > > > > > this is the case. It might explain why you
> > can't
> > > > > > > create
> > > > > > > > > >> > > > > > > > a
> > > > > > > > > >> > > > Confluence
> > > > > > > > > >> > > > > > > > space.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > My preference would be to just use the
> > website.
> > > > I
> > > > > > > think
> > > > > > > > > >> > > > > > > > it's
> > > > > > > > > >> > fine
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > > > > have a dev / design area of the website,
> > and we
> > > > > can
> > > > > > > > > >> > > > > > > > discuss on
> > > > > > > > > >> > > > GitHub
> > > > > > > > > >> > > > > > > > issues for the accumulo-website repo. That
> > is a
> > > > > bit
> > > > > > > > > >> > > > > > > > less
> > > > > > > > > >> > convenient
> > > > > > > > > >> > > > > > > > than Confluence if it's used heavily, but
> > it's
> > > > > more
> > > > > > > > > >> > > > > > > > convenient
> > > > > > > > > >> > in
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > > > sense that it's more accessible and fits
> > more in
> > > > > > line
> > > > > > > > > >> > > > > > > > with our
> > > > > > > > > >> > > > current
> > > > > > > > > >> > > > > > > > mode of operation. Plus, when a document is
> > > > final,
> > > > > > > it's
> > > > > > > > > >> > > > > > > > easy to
> > > > > > > > > >> > > > link
> > > > > > > > > >> > > > > > > > to from our documentation, without making
> > users
> > > > > jump
> > > > > > > to
> > > > > > > > > >> > > > > > > > another service to view docs.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > I would be opposed to using GitHub wiki or
> > a new
> > > > > git
> > > > > > > > repo.
> > > > > > > > > >> > > > > > > > We
> > > > > > > > > >> > have
> > > > > > > > > >> > > > > > > > enough repos. Although it seems like they
> > are
> > > > > free,
> > > > > > > > > >> > > > > > > > there is
> > > > > > > > > >> > still
> > > > > > > > > >> > > > a
> > > > > > > > > >> > > > > > > > lot of boilerplate work to maintain them,
> > from
> > > > > > > managing
> > > > > > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md,
> > > > etc.,
> > > > > to
> > > > > > > > > >> > .asf.yaml, to
> > > > > > > > > >> > > > > > > > README, to keeping copyright dates updated
> > in
> > > > the
> > > > > > > > > >> > > > > > > > NOTICE file,
> > > > > > > > > >> > and
> > > > > > > > > >> > > > > > > > more.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > In summary, my preference:
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > 1. Keep a space in accumulo-website,
> > discuss on
> > > > GH
> > > > > > > > > >> > > > > > > > issues and
> > > > > > > > > >> > > > mailing
> > > > > > > > > >> > > > > > > > list (strongly preferred) 2. Confluence,
> > discuss
> > > > > on
> > > > > > > > > >> > > > > > > > mailing list (prefer over other
> > > > > > > > > >> > options,
> > > > > > > > > >> > > > but
> > > > > > > > > >> > > > > > > > not a fan)
> > > > > > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list
> > > > (strongly
> > > > > > > > > >> > > > > > > > prefer not
> > > > > > > > > >> > to use
> > > > > > > > > >> > > > > > this
> > > > > > > > > >> > > > > > > > option)
> > > > > > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> > > > > mailing
> > > > > > > > > >> > > > > > > > list
> > > > > > > > > >> > (strongly
> > > > > > > > > >> > > > > > > > prefer not to use this option)
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > > > > > >> > edcoleman@apache.org>
> > > > > > > > > >> > > > > > wrote:
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > Currently, asf cannot create new wiki's
> > > > because
> > > > > > of a
> > > > > > > > > >> > Confluence
> > > > > > > > > >> > > > > > issue (
> > > > > > > > > >> > > > > > > >
> > > > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > )
> > > > > > I
> > > > > > > > > >> > > > > > > > chatted
> > > > > > > > > >> > with
> > > > > > > > > >> > > > > > infra
> > > > > > > > > >> > > > > > > > and in response they created that issue.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > To expand on this discussion, I would
> > like to
> > > > > toss
> > > > > > > > > >> > > > > > > > > out
> > > > > > > > > >> > another
> > > > > > > > > >> > > > > > > > alternative to discuss / explore. What if
> > we
> > > > > used a
> > > > > > > > > >> > > > > > > > separate
> > > > > > > > > >> > > > GitHub
> > > > > > > > > >> > > > > > > > project, something like Accumulo-Design,
> > just
> > > > > like
> > > > > > > > > >> > accumulo-proxy
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > > > > > > accumulo-examples. As a separate project,
> > it
> > > > > would
> > > > > > be
> > > > > > > > > >> > available
> > > > > > > > > >> > > > for
> > > > > > > > > >> > > > > > > > collaboration for the community, but remain
> > > > > separate
> > > > > > > > > >> > > > > > > > from main
> > > > > > > > > >> > > > project
> > > > > > > > > >> > > > > > and
> > > > > > > > > >> > > > > > > > the website to keep current code /
> > > > documentation /
> > > > > > > > > >> > > > > > > > design
> > > > > > > > > >> > clearly
> > > > > > > > > >> > > > > > separate
> > > > > > > > > >> > > > > > > > from speculative design discussions. As a
> > > > > project:
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > - document history would be preserved
> > with git
> > > > > > > commit
> > > > > > > > > >> > history.
> > > > > > > > > >> > > > > > > > > - document collaboration could be done
> > with
> > > > > normal
> > > > > > > PR
> > > > > > > > > >> > > > submissions /
> > > > > > > > > >> > > > > > > > reviews.
> > > > > > > > > >> > > > > > > > > - issues could be used to discuss design
> > > > > aspects,
> > > > > > > > > >> > > > > > > > > capturing
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > > comment
> > > > > > > > > >> > > > > > > > history.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > The biggest downside is that it would be
> > yet
> > > > > > another
> > > > > > > > > >> > > > > > > > > project
> > > > > > > > > >> > to
> > > > > > > > > >> > > > > > follow /
> > > > > > > > > >> > > > > > > > track.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > For me, I think the issue is that we need
> > a
> > > > > > public,
> > > > > > > > > >> > collaborative
> > > > > > > > > >> > > > > > space
> > > > > > > > > >> > > > > > > > to hold design discussions. Neither the main
> > > > > project
> > > > > > > or
> > > > > > > > > >> > > > > > > > the
> > > > > > > > > >> > > > web-site
> > > > > > > > > >> > > > > > seem
> > > > > > > > > >> > > > > > > > quite appropriate and Confluence seems to
> > lack
> > > > the
> > > > > > > > > >> > collaboration
> > > > > > > > > >> > > > that
> > > > > > > > > >> > > > > > can
> > > > > > > > > >> > > > > > > > be achieved with github.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > We need a space to capture the redesign
> > and
> > > > > > whatever
> > > > > > > > > >> > > > > > > > > we
> > > > > > > > > >> > select
> > > > > > > > > >> > > > can be
> > > > > > > > > >> > > > > > > > made to work - I'm just wondering what
> > provides
> > > > > the
> > > > > > > > > >> > > > > > > > easiest
> > > > > > > > > >> > forum
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > > build
> > > > > > > > > >> > > > > > > > a collaborative space for the Accumulo
> > > > community.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > Ed Coleman
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > On 2023/02/28 16:35:31
> > dlmarion@comcast.net
> > > > > > wrote:
> > > > > > > > > >> > > > > > > > > > Circling back on this issue - I agree
> > that
> > > > > > > comments
> > > > > > > > > >> > > > > > > > > > and
> > > > > > > > > >> > such
> > > > > > > > > >> > > > make
> > > > > > > > > >> > > > > > > > sense for internal design documents. I'm
> > going
> > > > to
> > > > > > > > > >> > > > > > > > create an
> > > > > > > > > >> > INFRA
> > > > > > > > > >> > > > > > ticket
> > > > > > > > > >> > > > > > > > for a cwiki space for Accumulo unless there
> > are
> > > > > any
> > > > > > > > > >> objections.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > -----Original Message-----
> > > > > > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16
> > PM
> > > > > > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github
> > wiki in
> > > > > > > > asf.yaml?
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > As mentioned, wikis can provide a
> > > > streamlined
> > > > > > > > > >> > > > > > > > > > collaborative
> > > > > > > > > >> > > > editing
> > > > > > > > > >> > > > > > > > workflow that's less labor intensive than
> > > > > updating a
> > > > > > > > > >> website.
> > > > > > > > > >> > They
> > > > > > > > > >> > > > can
> > > > > > > > > >> > > > > > > > promote collaboration by providing specific
> > > > > tooling
> > > > > > to
> > > > > > > > > >> > > > > > > > support
> > > > > > > > > >> > > > > > comments,
> > > > > > > > > >> > > > > > > > revisions and iteration.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > In terms of preservation, GH wikis act
> > just
> > > > > like
> > > > > > > > > >> > > > > > > > > > any other
> > > > > > > > > >> > Git
> > > > > > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > > > > > git@github.com
> > > > > > > > > :
> > > > > > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > > > > > >> > > > > > > > > > IIRC the pages are just GH flavored
> > > > markdown.
> > > > > > > There
> > > > > > > > > >> > > > > > > > > > are at
> > > > > > > > > >> > > > least a
> > > > > > > > > >> > > > > > few
> > > > > > > > > >> > > > > > > > Apache projects using them.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > However, GH wikis lack some features
> > that I
> > > > > feel
> > > > > > > > > >> > > > > > > > > > are
> > > > > > > > > >> > important
> > > > > > > > > >> > > > to
> > > > > > > > > >> > > > > > > > support collaborative authoring. For
> > example,
> > > > the
> > > > > > > > > >> > > > > > > > ability to
> > > > > > > > > >> > > > comment
> > > > > > > > > >> > > > > > and
> > > > > > > > > >> > > > > > > > discuss specific passages in a document is a
> > > > > feature
> > > > > > > > > >> > > > > > > > that's
> > > > > > > > > >> > > > present in
> > > > > > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come
> > appreciate
> > > > > > this
> > > > > > > > > >> > > > > > > > this in
> > > > > > > > > >> > my
> > > > > > > > > >> > > > google
> > > > > > > > > >> > > > > > > > docs and office workflows, so expect that it
> > > > would
> > > > > > be
> > > > > > > > > >> > > > > > > > useful
> > > > > > > > > >> > for
> > > > > > > > > >> > > > > > Accumulo
> > > > > > > > > >> > > > > > > > design discussions too.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith
> > > > Turner <
> > > > > > > > > >> > > > kturner@apache.org>
> > > > > > > > > >> > > > > > > > wrote:
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > > > > > documents,
> > > > > > > > > >> > > > > > > > > > > I think
> > > > > > > > > >> > it
> > > > > > > > > >> > > > > > would be
> > > > > > > > > >> > > > > > > > > > > less cumbersome than the website and
> > we
> > > > can
> > > > > > > > > >> > > > > > > > > > > always link
> > > > > > > > > >> > from
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > > > > > > website and issues to the wiki. I
> > think
> > > > its
> > > > > > ok
> > > > > > > > > >> > > > > > > > > > > to give
> > > > > > > > > >> > it a
> > > > > > > > > >> > > > try
> > > > > > > > > >> > > > > > and
> > > > > > > > > >> > > > > > > > > > > abandon it in the future, if abandoned
> > > > would
> > > > > > > just
> > > > > > > > > >> > > > > > > > > > > need to
> > > > > > > > > >> > > > > > properly
> > > > > > > > > >> > > > > > > > > > > communicate that. The content should
> > be
> > > > > > > archived
> > > > > > > > > >> > > > > > > > > > > in
> > > > > > > > > >> > Apache
> > > > > > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does
> > not do
> > > > > that
> > > > > > > > > >> > > > > > > > > > > then we
> > > > > > > > > >> > should
> > > > > > > > > >> > > > > > not use
> > > > > > > > > >> > > > > > > > > > > it. If GH wiki is not an option then
> > > > could
> > > > > > try
> > > > > > > > > cwiki.
> > > > > > > > > >> > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I reverted the change. I didn't
> > think it
> > > > > > would
> > > > > > > > > >> > > > > > > > > > > > be a big
> > > > > > > > > >> > > > deal,
> > > > > > > > > >> > > > > > but
> > > > > > > > > >> > > > > > > > if
> > > > > > > > > >> > > > > > > > > > > > it
> > > > > > > > > >> > > > > > > > > > > requires discussion, then let's
> > discuss
> > > > it.
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I'm looking for a place to host
> > > > > information
> > > > > > > > > >> > > > > > > > > > > > related to
> > > > > > > > > >> > > > internal
> > > > > > > > > >> > > > > > > > > > > > design
> > > > > > > > > >> > > > > > > > > > > discussions. I envision these to be
> > living
> > > > > > > > > >> > > > > > > > > > > documents that
> > > > > > > > > >> > > > will be
> > > > > > > > > >> > > > > > > > > > > updated over time as the
> > > > > design/implementation
> > > > > > > > > >> > progresses and
> > > > > > > > > >> > > > > > that
> > > > > > > > > >> > > > > > > > > > > other committers will be able to
> > comment
> > > > on
> > > > > > and
> > > > > > > > > >> > > > > > > > > > > edit. I
> > > > > > > > > >> > don't
> > > > > > > > > >> > > > > > feel
> > > > > > > > > >> > > > > > > > > > > that the website is the correct place
> > for
> > > > > this
> > > > > > > > > >> because:
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > > > > > discussions
> > > > > > > > > >> > > > > > > > > > > > should
> > > > > > > > > >> > go
> > > > > > > > > >> > > > on the
> > > > > > > > > >> > > > > > > > > > > > project
> > > > > > > > > >> > > > > > > > > > > website.
> > > > > > > > > >> > > > > > > > > > > > 2. Changes to the design documents
> > > > could
> > > > > > not
> > > > > > > > > >> > > > > > > > > > > > be seen
> > > > > > > > > >> > by
> > > > > > > > > >> > > > > > others
> > > > > > > > > >> > > > > > > > > > > > right
> > > > > > > > > >> > > > > > > > > > > away (IIRC changes to the website are
> > > > built
> > > > > > and
> > > > > > > > > >> > available at
> > > > > > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/,
> > but
> > > > > > human
> > > > > > > > > >> > intervention
> > > > > > > > > >> > > > is
> > > > > > > > > >> > > > > > > > > > > required to publish it at
> > > > > > > > > >> https://accumulo.apache.org/).
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I looked in the INFRA issues and
> > other
> > > > > > > projects
> > > > > > > > > >> > > > > > > > > > > > are
> > > > > > > > > >> > using
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > GH
> > > > > > > > > >> > > > > > > > > > > > Wiki
> > > > > > > > > >> > > > > > > > > > > feature and I saw no mention of
> > backing it
> > > > > up
> > > > > > or
> > > > > > > > > >> > > > > > > > > > > the
> > > > > > > > > >> > > > requirement
> > > > > > > > > >> > > > > > to
> > > > > > > > > >> > > > > > > > do
> > > > > > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing
> > it
> > > > > up?).
> > > > > > > It
> > > > > > > > > >> > > > > > > > > > > does
> > > > > > > > > >> > appear
> > > > > > > > > >> > > > > > that we
> > > > > > > > > >> > > > > > > > > > > would need an INFRA ticket so that
> > they
> > > > can
> > > > > > > > > >> > > > > > > > > > > modify the
> > > > > > > > > >> > GitHub
> > > > > > > > > >> > > > > > project
> > > > > > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down
> > so
> > > > > that
> > > > > > > > > >> > > > > > > > > > > only
> > > > > > > > > >> > > > committers can
> > > > > > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not
> > > > acceptable,
> > > > > > > then
> > > > > > > > > >> > > > > > > > > > > I think
> > > > > > > > > >> > > > Apache
> > > > > > > > > >> > > > > > > > > > > Confluence (
> > > > > > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > > > > > acceptable
> > > > > > > > > >> > > > alternative.
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > >> > > > > > > > > > > > From: Christopher <
> > ctubbsii@apache.org>
> > > > > > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023
> > 4:41
> > > > AM
> > > > > > > > > >> > > > > > > > > > > > To: accumulo-dev <
> > > > dev@accumulo.apache.org
> > > > > >
> > > > > > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> > > > > updated:
> > > > > > > > > >> > > > > > > > > > > > Enable
> > > > > > > > > >> > Github
> > > > > > > > > >> > > > > > wiki in
> > > > > > > > > >> > > > > > > > > > > asf.yaml
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > I don't recall a discussion about
> > this
> > > > > > change,
> > > > > > > > > >> > > > > > > > > > > > but I
> > > > > > > > > >> > think
> > > > > > > > > >> > > > it
> > > > > > > > > >> > > > > > goes
> > > > > > > > > >> > > > > > > > > > > against previous efforts to make the
> > > > website
> > > > > > the
> > > > > > > > > >> > > > > > > > > > > one
> > > > > > > > > >> > > > canonical
> > > > > > > > > >> > > > > > > > > > > location for our documentation. I
> > don't
> > > > even
> > > > > > > > > >> > > > > > > > > > > think infra
> > > > > > > > > >> > is
> > > > > > > > > >> > > > > > backing
> > > > > > > > > >> > > > > > > > up
> > > > > > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be
> > a
> > > > > record
> > > > > > > of
> > > > > > > > > >> > > > > > > > > > > the
> > > > > > > > > >> > wiki
> > > > > > > > > >> > > > > > contents
> > > > > > > > > >> > > > > > > > in
> > > > > > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which
> > is
> > > > > backed
> > > > > > > up
> > > > > > > > > >> > > > > > > > > > > to
> > > > > > > > > >> > GitBox
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > > > > > > > > > > issue tracker, which CCs the
> > notifications
> > > > > > > list).
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > In short, I think this should be
> > > > reverted
> > > > > > and
> > > > > > > > > >> > > > > > > > > > > > we
> > > > > > > > > >> > should not
> > > > > > > > > >> > > > > > use the
> > > > > > > > > >> > > > > > > > > > > GitHub wiki. If we need to store
> > documents
> > > > > in
> > > > > > a
> > > > > > > > > >> > > > > > > > > > > version
> > > > > > > > > >> > > > > > controlled
> > > > > > > > > >> > > > > > > > > > > way, we can store them on the
> > website, or
> > > > in
> > > > > > our
> > > > > > > > > >> > project's
> > > > > > > > > >> > > > SVN
> > > > > > > > > >> > > > > > dev
> > > > > > > > > >> > > > > > > > > > > space. The wiki is just another place
> > > > people
> > > > > > > > > >> > > > > > > > > > > would have
> > > > > > > > > >> > to
> > > > > > > > > >> > > > > > follow if
> > > > > > > > > >> > > > > > > > > > > they want to participate, and I don't
> > > > think
> > > > > > that
> > > > > > > > > >> > > > > > > > > > > serves
> > > > > > > > > >> > us.
> > > > > > > > > >> > > > > > > > Therefore,
> > > > > > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > This is an automated email from
> > the
> > > > ASF
> > > > > > > > > >> > > > > > > > > > > > > dual-hosted
> > > > > > > > > >> > git
> > > > > > > > > >> > > > > > > > repository.
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch
> > > > main
> > > > > in
> > > > > > > > > >> > > > > > > > > > > > > repository
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > > > > > >> > > > > > > > > > > > > git
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > The following commit(s) were
> > added to
> > > > > > > > > >> > refs/heads/main by
> > > > > > > > > >> > > > this
> > > > > > > > > >> > > > > > > > push:
> > > > > > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github
> > wiki
> > > > > in
> > > > > > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > > > > > >> > > > > > ae8a817e7b is
> > > > > > > > > >> > > > > > > > > > > > > described below
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > commit
> > > > > > > > > >> > > > > > > > > > > > >
> > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> > > > > dlmarion@apache.org>
> > > > > > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10
> > 2023
> > > > > -0500
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > >> > > > > > > > > > > > > ---
> > > > > > > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml
> > > > index
> > > > > > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > > > > > >> > > > > > > > > > > > > 100644
> > > > > > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > >> > > > > > > > > > > > > - big-data
> > > > > > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > > > > > >> > > > > > > > > > > > > features:
> > > > > > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > > > > > >> > > > > > > > > > > > > issues: true
> > > > > > > > > >> > > > > > > > > > > > > projects: true
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
This was just something I found to answer the issue of notifications,
issues, and PRs. I think the main difference is that it's immediately
available on the GitHub site for viewing vs having to wait for it to be
published to the website and that we're not publishing draft or WIP design
documents to the website. I still think that Confluence is a better option
regarding comments and discussion, hopefully infra can figure that out.
On Thu, Mar 16, 2023 at 7:51 AM Christopher <ct...@apache.org> wrote:
> Isn't that basically the same as how the website repo works? How would
> that be different then?
>
> On Wed, Mar 15, 2023 at 2:55 PM Dave Marion <dm...@gmail.com> wrote:
> >
> > It looks like we could generate the GH wiki from a folder in the source
> > code. This would allow for issues and PRs. Just a thought.
> >
> > Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
> >
> https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
> >
> > On Wed, Mar 15, 2023 at 2:16 PM Christopher <ct...@apache.org> wrote:
> >
> > > It seems like there's a majority consensus of those engaged. No need
> for a
> > > vote, but I think the question about notifications should be addressed
> > > first.
> > >
> > > On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
> > > christopher.l.shannon@gmail.com> wrote:
> > >
> > > > I'm +1 to using some kind of wiki so if we can't use Confluence then
> GH
> > > > sounds fine to me. Do we need to take a formal vote for using the
> Github
> > > > wiki or is there enough consensus already?
> > > >
> > > > On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com>
> > > wrote:
> > > >
> > > > > +1 for the GH wiki with major discussions still being fed into, or
> > > > > originated on the mailing lists.
> > > > >
> > > > > As a side question, if there is a lengthy discussion on a GH
> issue, is
> > > it
> > > > > standard practice to just recap that in a mailing list message?
> > > > > Or is there a more "formal" inclusion process to follow?
> > > > >
> > > > >
> > > > > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org>
> > > wrote:
> > > > >
> > > > > > I don't think the workflow I proposed about using PRs and
> discussion
> > > on
> > > > > > tickets, etc. and the accompanying arguments about keeping things
> > > > > > consolidated and accessible to potential contributors not
> > > participating
> > > > > on
> > > > > > GitHub, were really challenged at all. However, since I seem to
> be
> > > the
> > > > > only
> > > > > > one advocating for using the website, to keep things
> centralized, as
> > > > per
> > > > > > previous attempts to consolidate documentation, I won't fight
> the use
> > > > of
> > > > > > GitHub wiki. But I do want to make it clear that we're
> proceeding in
> > > > that
> > > > > > direction under my objection (-0), and that I'm not convinced
> this is
> > > > the
> > > > > > best path forward. Hopefully, I will be proven wrong in time.
> > > > > >
> > > > > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com>
> wrote:
> > > > > >
> > > > > > > > At this point, I think we should move forward with a GH wiki
> and
> > > > then
> > > > > > we
> > > > > > > can re-evaluate things once the Apache confluence issue is
> sorted
> > > > out.
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com>
> wrote:
> > > > > > >
> > > > > > > > I just tried (Wed, 3/15) and still received the same error.
> I
> > > > asked
> > > > > on
> > > > > > > > the infra slack channel and they replied that they are still
> > > > working
> > > > > to
> > > > > > > > determine what the issue is - signs are pointing to something
> > > > inside
> > > > > of
> > > > > > > > confluence, but no progress.
> > > > > > > >
> > > > > > > > At this point, I think we should move forward with a GH wiki
> and
> > > > then
> > > > > > we
> > > > > > > > can re-evaluate things once the Apache confluence issue is
> sorted
> > > > > out.
> > > > > > > >
> > > > > > > > Ed Coleman
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Dave Marion <dm...@gmail.com>
> > > > > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > >
> > > > > > > > Looking at the Infra slack channel response, one of the
> responses
> > > > in
> > > > > > the
> > > > > > > > channel said that "it's some sort of db corruption according
> to
> > > > > > > Atlassian".
> > > > > > > > Doesn't sound good....
> > > > > > > >
> > > > > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <
> dmarion18@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > > > > unresolved
> > > > > > > > > and the only comment on the ticket is one that Ed added two
> > > days
> > > > > ago
> > > > > > > > > requesting an ACCUMULO wiki space.
> > > > > > > > >
> > > > > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > >> I do not see any comments in the infa slack channel - so
> no
> > > > > updates
> > > > > > > > >> for now.
> > > > > > > > >>
> > > > > > > > >> -----Original Message-----
> > > > > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > > > > >> To: dev@accumulo.apache.org
> > > > > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > >>
> > > > > > > > >> Right, I was just curious if there was any follow-up as I
> > > think
> > > > Ed
> > > > > > > > >> said that it was going to be discussed by the INFRA team
> > > > > yesterday.
> > > > > > > > >> There is at least one other recent ticket (
> > > > > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > > > > selfserve
> > > > > > > > >> had an issue and the INFRA team created the space
> manually.
> > > > > > > > >>
> > > > > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> > > > ctubbsii@apache.org>
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> > You can track that issue at
> > > > > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > > > > >> >
> > > > > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > > > > dmarion18@gmail.com>
> > > > > > > > >> wrote:
> > > > > > > > >> > >
> > > > > > > > >> > > Ed,
> > > > > > > > >> > >
> > > > > > > > >> > > Any update from INFRA on being able to create
> confluence
> > > > > > pages?
> > > > > > > > >> > >
> > > > > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > > > > ctubbsii@apache.org
> > > > > > >
> > > > > > > > >> wrote:
> > > > > > > > >> > >
> > > > > > > > >> > > > We've definitely used the website for more than
> that. We
> > > > use
> > > > > > it
> > > > > > > > >> > > > to document things for users, help developers know
> how
> > > to
> > > > > > > > >> > > > contribute, store drafts of designs, share user
> stories
> > > > via
> > > > > > > > >> > > > blogs, do release announcements, and more. There's
> > > > > definitely
> > > > > > > > >> > > > space on the website to do this kind of thing, if we
> > > want
> > > > > to.
> > > > > > > > >> > > > We've used it that way before. If you only see it
> as a
> > > > place
> > > > > > > > >> > > > "for user consumption after everything has been
> > > > finalized",
> > > > > > > > >> > > > then you're missing out on the other ways we
> currently
> > > use
> > > > > the
> > > > > > > > >> > > > site, and the ways we've used it in
> > > > > > > > >> the past.
> > > > > > > > >> > > >
> > > > > > > > >> > > > With the website, most of the collaboration would
> happen
> > > > in
> > > > > > the
> > > > > > > > >> > > > GH issues about proposed designs or changes to
> designs,
> > > > just
> > > > > > > > >> > > > like we do today with code or other documentation,
> which
> > > > > > > > >> > > > everybody is used to. I agree it's not as good as
> Google
> > > > > Docs
> > > > > > > > >> > > > for on-the-fly comments/annotations, but I don't
> think
> > > > > > > > >> > > > Confluence or Wiki are as good as that either, and
> > > Google
> > > > > Docs
> > > > > > > > isn't really an option...
> > > > > > > > >> > > > unless you just want to link to it in the mailing
> list
> > > and
> > > > > > > > >> > > > stick to Google Docs from your personal Google
> account,
> > > > > until
> > > > > > > > >> > > > it's ready for publication, which would also be fine
> > > (any
> > > > > > > > >> > > > interested persons can simply request write access
> by
> > > > > replying
> > > > > > > > >> > > > to the message where
> > > > > > > > >> you shared the link)..
> > > > > > > > >> > > >
> > > > > > > > >> > > > We are a much smaller project than many others, and
> we
> > > > have
> > > > > > > > >> > > > previously suffered from having stuff too spread
> out.
> > > Even
> > > > > if
> > > > > > > > >> > > > other projects find a separate space valuable for
> them,
> > > > I'm
> > > > > > not
> > > > > > > > >> > > > sure it's best for the Accumulo project. While I
> think
> > > > it's
> > > > > > > > >> > > > useful to examine what other projects do, I do
> think we
> > > > > should
> > > > > > > > >> > > > be careful to adopt anything just because others
> find it
> > > > > > > > convenient for them.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Confluence is my second choice, but with a big gap
> > > between
> > > > > it
> > > > > > > > >> > > > and my first choice.
> > > > > > > > >> > > >
> > > > > > > > >> > > > On a personal note: I hate using Confluence,
> because I
> > > > think
> > > > > > > > >> > > > the navigation is highly unintuitive, as is the
> > > > permissions
> > > > > > > > >> > > > model, and I don't like the idea of learning yet
> another
> > > > > > > > >> > > > wiki-syntax (though I've read Confluence supports
> some
> > > > > limited
> > > > > > > > >> > > > Markdown, but probably not the same as
> GitHub/Jekyll). I
> > > > > also
> > > > > > > > >> > > > do not want to set up custom notifications for
> watching
> > > > yet
> > > > > > > > >> > > > another space. If we use Confluence, I will probably
> > > > > > contribute
> > > > > > > > >> > > > very infrequently there because of my frustrations
> with
> > > > > having
> > > > > > > > >> > > > used it before. However, that would be my choice,
> and
> > > > should
> > > > > > > > >> > > > not be a reason the project chooses one over
> another.
> > > I'm
> > > > > > > > >> > > > sharing my personal opinion only because it is
> > > influencing
> > > > > my
> > > > > > > > >> > > > opinion about the website being more accessible,
> via our
> > > > > > > > >> > > > current GitHub PR/issue/Markdown workflows, and I
> wonder
> > > > how
> > > > > > > > >> > > > many other potential contributors would feel
> similarly.
> > > > It's
> > > > > > > > >> > > > hard to know, since it seems like a lot of this is
> > > > > subjective,
> > > > > > > > >> > > > and is going to come down to a consensus of personal
> > > > > > > > >> preferences.
> > > > > > > > >> > > >
> > > > > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > > > > >> > > > <dm...@gmail.com>
> > > > > > > > >> > wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > I don't see the website as an area where we would
> have
> > > > > > > > >> > > > > collaborative discussions about an idea. For
> example,
> > > > > making
> > > > > > > > >> > > > > comments and
> > > > > > > > >> > suggestions
> > > > > > > > >> > > > on
> > > > > > > > >> > > > > a document like you can do in Google Docs. I see
> the
> > > > > website
> > > > > > > > >> > > > > as a
> > > > > > > > >> > place
> > > > > > > > >> > > > > where items are documented for user consumption
> after
> > > > > > > > >> > > > > everything has
> > > > > > > > >> > been
> > > > > > > > >> > > > > finalized. I'm not trying to create a private
> > > discussion
> > > > > > > > >> > > > > area, I
> > > > > > > > >> > think
> > > > > > > > >> > > > > anyone can see the wiki (but I think anonymous
> > > comments
> > > > > are
> > > > > > > > >> > > > > disabled
> > > > > > > > >> > due
> > > > > > > > >> > > > to
> > > > > > > > >> > > > > spam issues). I see no issue with putting
> > > > work-in-progress
> > > > > > > > >> > > > > documents
> > > > > > > > >> > on a
> > > > > > > > >> > > > > wiki and referencing them via emails to the dev
> list.
> > > I
> > > > > > think
> > > > > > > > >> > > > > this is
> > > > > > > > >> > > > done
> > > > > > > > >> > > > > in a lot of other projects. Non-committers that
> don't
> > > > have
> > > > > > > > >> > > > > access to
> > > > > > > > >> > the
> > > > > > > > >> > > > > wiki and want to make comments, suggestions, and
> ask
> > > > > > > > >> > > > > questions can
> > > > > > > > >> > do so
> > > > > > > > >> > > > > via the mailing list. I think it's also possible
> that
> > > > > people
> > > > > > > > >> > > > > can get confluence accounts (see
> > > > > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > > > > >> > > > > so if a non-committer wanted to participate they
> > > could.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > > > > >> > > > > <ct...@apache.org>
> > > > > > > > >> > wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > > > > >> > > > > > <dm...@gmail.com>
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > I'm opposed to using the website for the
> reasons I
> > > > > > > > >> > > > > > > specified
> > > > > > > > >> > > > earlier, so
> > > > > > > > >> > > > > > it
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Your reasons that I saw were:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > 1. I don't think internal design discussions
> > > should
> > > > go
> > > > > > on
> > > > > > > > >> > > > > > > the
> > > > > > > > >> > project
> > > > > > > > >> > > > > > website.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > That doesn't look to me like a reason. That
> appears
> > > to
> > > > > > just
> > > > > > > > >> > > > > > be
> > > > > > > > >> > stating
> > > > > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > 2. Changes to the design documents could not
> be
> > > seen
> > > > > by
> > > > > > > > >> > > > > > > others
> > > > > > > > >> > right
> > > > > > > > >> > > > > > away (IIRC changes to the website are built and
> > > > > available
> > > > > > > > >> > > > > > at https://accumulo.staged.apache.org/, but
> human
> > > > > > > > >> > > > > > intervention is
> > > > > > > > >> > > > required
> > > > > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > What do you mean by "others" here? Do you mean
> > > > "users",
> > > > > as
> > > > > > > > >> > > > > > opposed
> > > > > > > > >> > to
> > > > > > > > >> > > > > > "developers/contributors"? The ASF draws a
> > > distinction
> > > > > > > > >> > > > > > between "developers/contributors" and "users"
> as it
> > > > > > > > >> > > > > > pertains to official releases. Releases are
> intended
> > > > to
> > > > > be
> > > > > > > > >> > > > > > consumed by users, and pre-release stuff is
> intended
> > > > to
> > > > > be
> > > > > > > > >> > > > > > collaborative, open to all potential
> > > > > > > > >> > > > > > developers/contributors. Very very rarely are
> things
> > > > > > > > >> > > > > > reserved exclusively for committers. We don't
> even
> > > > have
> > > > > a
> > > > > > > > >> > > > > > private committers space (the private mailing
> list
> > > is
> > > > > > > > >> > > > > > PMC-private, not committer-private). Having a
> > > > > distinction
> > > > > > > > >> > > > > > between users and
> > > > > > > > >> > developers
> > > > > > > > >> > > > > > doesn't mean we can't publish things on the
> > > website...
> > > > > it
> > > > > > > > >> > > > > > just
> > > > > > > > >> > means
> > > > > > > > >> > > > > > that we should be careful about how we do it,
> which
> > > is
> > > > > the
> > > > > > > > >> > > > > > same
> > > > > > > > >> > care
> > > > > > > > >> > > > > > we should take regardless of where we put it.
> > > > > > Specifically,
> > > > > > > > >> > > > > > the
> > > > > > > > >> > care
> > > > > > > > >> > > > > > we need to take is to avoid marketing
> pre-release
> > > > > content
> > > > > > > > >> > > > > > to
> > > > > > > > >> users.
> > > > > > > > >> > > > > > One way we can exercise this care for content
> on our
> > > > > > > > >> > > > > > website is
> > > > > > > > >> > that
> > > > > > > > >> > > > > > we can avoid sharing these unpolished designs by
> > > > simply
> > > > > > not
> > > > > > > > >> > > > > > linking them on the site, or by placing them in
> an
> > > > area
> > > > > > > > >> > > > > > that is clearly
> > > > > > > > >> > marked
> > > > > > > > >> > > > > > as intended for devs. But, we have no similar
> > > > > distinction
> > > > > > > > >> > > > > > between committers and non-committer devs for
> which
> > > we
> > > > > > > > >> > > > > > should avoid sharing pre-release content under
> > > > > > development.
> > > > > > > > >> > > > > > In fact, it is the
> > > > > > > > >> > opposite...
> > > > > > > > >> > > > > > we should be developing openly so as to allow
> room
> > > for
> > > > > > > > >> > non-committers
> > > > > > > > >> > > > > > to become committers through participation in
> > > > > development
> > > > > > > > >> > activities.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > As for the staging/publication of the website,
> > > that's
> > > > > just
> > > > > > > > >> > > > > > a
> > > > > > > > >> > mechanic
> > > > > > > > >> > > > > > for verifying the website isn't broken before we
> > > serve
> > > > > it.
> > > > > > > > >> > > > > > It's
> > > > > > > > >> > not a
> > > > > > > > >> > > > > > mechanism for keeping things internal vs.
> shared and
> > > > > > > > >> > > > > > doesn't have anything to do with the separation
> > > > between
> > > > > > > > >> > > > > > devs and users. We
> > > > > > > > >> > already
> > > > > > > > >> > > > > > publish Draft contents to the website, as well
> as
> > > > > > > > >> > developer-specific
> > > > > > > > >> > > > > > documentation not intended for users.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > We've even specifically published
> work-in-progress
> > > > > design
> > > > > > > > >> > > > > > documents there, of the same type that seems to
> be
> > > the
> > > > > > > > >> > > > > > basis of this conversation (
> > > > > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > > > > >> > I
> > > > > > > > >> > > > > > would strongly prefer us to continue to do it
> this
> > > > way,
> > > > > > > > >> > > > > > rather than create a new space, and have these
> kinds
> > > > of
> > > > > > > > >> > > > > > things scattered in multiple places.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > If, on the other hand, you intend to say that
> these
> > > > > should
> > > > > > > > >> > > > > > be
> > > > > > > > >> > private
> > > > > > > > >> > > > > > because they aren't ready for other potential
> > > > > > contributors,
> > > > > > > > >> > > > > > then I would argue that we're an openly
> developed
> > > > > > project...
> > > > > > > > >> > > > > > if something isn't ready to be shared with other
> > > > > potential
> > > > > > > > >> > > > > > contributors / developers, such that you want to
> > > keep
> > > > it
> > > > > > > > >> > > > > > internal to existing committers, then it's not
> ready
> > > > to
> > > > > be
> > > > > > > > >> > > > > > contributed to the project at all... because we
> > > don't
> > > > > > > > >> > > > > > restrict collaboration to only existing
> committers.
> > > > That
> > > > > > > > >> > > > > > would prevent others from participating and
> > > > > > > > >> > earning
> > > > > > > > >> > > > > > the merit to become committers, and that's not
> > > > something
> > > > > > we
> > > > > > > > >> > > > > > should
> > > > > > > > >> > be
> > > > > > > > >> > > > > > doing. Anything that is okay to share with
> existing
> > > > > > > > >> > > > > > committers
> > > > > > > > >> > should
> > > > > > > > >> > > > > > be okay to share to other potential
> contributors who
> > > > > want
> > > > > > > > >> > > > > > to participate, and should be done in a space
> that
> > > > > allows
> > > > > > > > >> > > > > > them to do that. The website is a perfect space
> for
> > > > > that,
> > > > > > > > >> > > > > > and has everything
> > > > > > > > >> > we
> > > > > > > > >> > > > > > need. I'm actually not sure about Confluence...
> I
> > > > > suspect
> > > > > > > > >> > > > > > non-committers wouldn't be able to participate
> there
> > > > > > > > >> > > > > > because they probably can't get accounts for it.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > looks like we need to
> > > > > > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be
> curious
> > > how
> > > > > > much
> > > > > > > > >> > > > > > > we
> > > > > > > > >> > need to
> > > > > > > > >> > > > use
> > > > > > > > >> > > > > > > the mailing list during
> > > > > > > > >> > > > > > > the design phase. We can announce meeting
> > > > dates/times
> > > > > on
> > > > > > > > >> > > > > > > the
> > > > > > > > >> > mailing
> > > > > > > > >> > > > list
> > > > > > > > >> > > > > > > and post links to
> > > > > > > > >> > > > > > > meeting notes in Confluence. Ultimately,
> decisions
> > > > > made
> > > > > > > > >> > > > > > > by the
> > > > > > > > >> > people
> > > > > > > > >> > > > > > that
> > > > > > > > >> > > > > > > want to be involved
> > > > > > > > >> > > > > > > will turn into pull requests against the
> codebase
> > > > > which
> > > > > > > > >> > comitters can
> > > > > > > > >> > > > > > weigh
> > > > > > > > >> > > > > > > in on. When you say,
> > > > > > > > >> > > > > > > "... but decisions about those would still
> need to
> > > > be
> > > > > > > > >> > > > > > > done on the
> > > > > > > > >> > > > mailing
> > > > > > > > >> > > > > > > list." Are you saying that we need to discuss
> > > every
> > > > > > > > >> > > > > > > single design decision on the mailing
> > > > > > > > >> > list?
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Yes and no. I am saying that decisions need to
> > > happen
> > > > on
> > > > > > > > >> > > > > > the
> > > > > > > > >> > mailing
> > > > > > > > >> > > > > > list, but I agree with you that this can be
> > > satisfied
> > > > > > > > >> > > > > > through pull requests. I just wanted to
> emphasize
> > > that
> > > > > > > > >> > > > > > regardless of where we do that pre-decision
> > > > > collaboration,
> > > > > > > > >> > > > > > that collaboration should not be misconstrued
> as a
> > > > > > decision
> > > > > > > > >> > > > > > to
> > > > > > > > >> accept those ideas into the project.
> > > > > > > > >> > The
> > > > > > > > >> > > > > > decision occurs during the PR or other activity
> that
> > > > > > > > >> > > > > > interfaces
> > > > > > > > >> > with
> > > > > > > > >> > > > > > the mailing list, subsequent to the
> collaboration in
> > > > the
> > > > > > > > >> > design/idea
> > > > > > > > >> > > > > > phase.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > As for the pre-decision collaboration space
> we're
> > > > > > > > >> > > > > > discussing, I
> > > > > > > > >> > just
> > > > > > > > >> > > > > > want to be careful that we're not creating such
> a
> > > > space
> > > > > in
> > > > > > > > >> > > > > > an exclusionary way that allows only existing
> > > > committers
> > > > > > to
> > > > > > > > >> > participate,
> > > > > > > > >> > > > > > that excludes other potential contributors.
> This is
> > > > > still
> > > > > > > > >> > > > > > an openly-developed project, and we should
> > > collaborate
> > > > > in
> > > > > > a
> > > > > > > > >> > > > > > space
> > > > > > > > >> > that is
> > > > > > > > >> > > > > > not exclusive to existing committers, but open
> to
> > > > > > > > >> > > > > > non-committer contributors and potential
> > > contributors
> > > > as
> > > > > > > well.
> > > > > > > > >> > > > > > So, while we may
> > > > > > > > >> > want
> > > > > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > > > > >> > > > > > consumption (an important separation that
> relates to
> > > > > > > > >> > > > > > official ASF releases), we
> > > > > > > > >> > should
> > > > > > > > >> > > > > > not be drawing a line between committer-devs as
> > > > > "internal"
> > > > > > > > >> > > > > > and contributor-devs as "external". The website,
> > > with
> > > > > its
> > > > > > > > >> > > > > > own issue tracker, the ability to render
> markdown,
> > > do
> > > > > > > > >> > > > > > reviews, and collaboratively edit, seems like
> the
> > > > ideal
> > > > > > > > >> > > > > > place to me. We've used
> > > > > > > > >> > it
> > > > > > > > >> > > > > > before for the same purpose, and I think we
> should
> > > > > > continue
> > > > > > > > >> > > > > > to do
> > > > > > > > >> > so.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > > > > >> > >
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > > So, I agree a space would be helpful.
> Although
> > > > it's
> > > > > > old
> > > > > > > > >> > > > > > > > school
> > > > > > > > >> > and
> > > > > > > > >> > > > > > > > inconvenient, the mailing list is the
> canonical
> > > > > place
> > > > > > > > >> > > > > > > > for
> > > > > > > > >> > > > discussion.
> > > > > > > > >> > > > > > > > We currently use GitHub issues a lot, but
> that's
> > > > > > copied
> > > > > > > > >> > > > > > > > to a
> > > > > > > > >> > > > mailing
> > > > > > > > >> > > > > > > > list (as is our old JIRA space), so if
> people
> > > want
> > > > > to
> > > > > > > > >> > participate
> > > > > > > > >> > > > > > > > without a GitHub account, they can still do
> > > that.
> > > > > > There
> > > > > > > > >> > > > > > > > are
> > > > > > > > >> > certain
> > > > > > > > >> > > > > > > > options that are perhaps less convenient,
> such
> > > as
> > > > > just
> > > > > > > > >> > > > > > > > using
> > > > > > > > >> > the
> > > > > > > > >> > > > > > > > mailing list and our dev SVN space, but
> still
> > > more
> > > > > > > > >> > > > > > > > appropriate
> > > > > > > > >> > than
> > > > > > > > >> > > > > > > > options that would be less ubiquitous for
> > > > potential
> > > > > > > > >> > participants.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > I think the ASF Confluence is probably
> fine, for
> > > > > > > > >> > > > > > > > storing,
> > > > > > > > >> > editing,
> > > > > > > > >> > > > and
> > > > > > > > >> > > > > > > > collaborating on shared documents, but
> decisions
> > > > > about
> > > > > > > > >> > > > > > > > those
> > > > > > > > >> > would
> > > > > > > > >> > > > > > > > still need to be done on the mailing list.
> If I
> > > > > > > > >> > > > > > > > remember
> > > > > > > > >> > > > correctly, we
> > > > > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > > > > >> > > > favor
> > > > > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > > > > >> > > > > > > > mis-remembering, but
> > > > > > > > >> > I
> > > > > > > > >> > > > think
> > > > > > > > >> > > > > > > > this is the case. It might explain why you
> can't
> > > > > > create
> > > > > > > > >> > > > > > > > a
> > > > > > > > >> > > > Confluence
> > > > > > > > >> > > > > > > > space.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > My preference would be to just use the
> website.
> > > I
> > > > > > think
> > > > > > > > >> > > > > > > > it's
> > > > > > > > >> > fine
> > > > > > > > >> > > > to
> > > > > > > > >> > > > > > > > have a dev / design area of the website,
> and we
> > > > can
> > > > > > > > >> > > > > > > > discuss on
> > > > > > > > >> > > > GitHub
> > > > > > > > >> > > > > > > > issues for the accumulo-website repo. That
> is a
> > > > bit
> > > > > > > > >> > > > > > > > less
> > > > > > > > >> > convenient
> > > > > > > > >> > > > > > > > than Confluence if it's used heavily, but
> it's
> > > > more
> > > > > > > > >> > > > > > > > convenient
> > > > > > > > >> > in
> > > > > > > > >> > > > the
> > > > > > > > >> > > > > > > > sense that it's more accessible and fits
> more in
> > > > > line
> > > > > > > > >> > > > > > > > with our
> > > > > > > > >> > > > current
> > > > > > > > >> > > > > > > > mode of operation. Plus, when a document is
> > > final,
> > > > > > it's
> > > > > > > > >> > > > > > > > easy to
> > > > > > > > >> > > > link
> > > > > > > > >> > > > > > > > to from our documentation, without making
> users
> > > > jump
> > > > > > to
> > > > > > > > >> > > > > > > > another service to view docs.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > I would be opposed to using GitHub wiki or
> a new
> > > > git
> > > > > > > repo.
> > > > > > > > >> > > > > > > > We
> > > > > > > > >> > have
> > > > > > > > >> > > > > > > > enough repos. Although it seems like they
> are
> > > > free,
> > > > > > > > >> > > > > > > > there is
> > > > > > > > >> > still
> > > > > > > > >> > > > a
> > > > > > > > >> > > > > > > > lot of boilerplate work to maintain them,
> from
> > > > > > managing
> > > > > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md,
> > > etc.,
> > > > to
> > > > > > > > >> > .asf.yaml, to
> > > > > > > > >> > > > > > > > README, to keeping copyright dates updated
> in
> > > the
> > > > > > > > >> > > > > > > > NOTICE file,
> > > > > > > > >> > and
> > > > > > > > >> > > > > > > > more.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > In summary, my preference:
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > 1. Keep a space in accumulo-website,
> discuss on
> > > GH
> > > > > > > > >> > > > > > > > issues and
> > > > > > > > >> > > > mailing
> > > > > > > > >> > > > > > > > list (strongly preferred) 2. Confluence,
> discuss
> > > > on
> > > > > > > > >> > > > > > > > mailing list (prefer over other
> > > > > > > > >> > options,
> > > > > > > > >> > > > but
> > > > > > > > >> > > > > > > > not a fan)
> > > > > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list
> > > (strongly
> > > > > > > > >> > > > > > > > prefer not
> > > > > > > > >> > to use
> > > > > > > > >> > > > > > this
> > > > > > > > >> > > > > > > > option)
> > > > > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> > > > mailing
> > > > > > > > >> > > > > > > > list
> > > > > > > > >> > (strongly
> > > > > > > > >> > > > > > > > prefer not to use this option)
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > > > > >> > edcoleman@apache.org>
> > > > > > > > >> > > > > > wrote:
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > Currently, asf cannot create new wiki's
> > > because
> > > > > of a
> > > > > > > > >> > Confluence
> > > > > > > > >> > > > > > issue (
> > > > > > > > >> > > > > > > >
> > > https://issues.apache.org/jira/browse/INFRA-24291
> > > > )
> > > > > I
> > > > > > > > >> > > > > > > > chatted
> > > > > > > > >> > with
> > > > > > > > >> > > > > > infra
> > > > > > > > >> > > > > > > > and in response they created that issue.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > To expand on this discussion, I would
> like to
> > > > toss
> > > > > > > > >> > > > > > > > > out
> > > > > > > > >> > another
> > > > > > > > >> > > > > > > > alternative to discuss / explore. What if
> we
> > > > used a
> > > > > > > > >> > > > > > > > separate
> > > > > > > > >> > > > GitHub
> > > > > > > > >> > > > > > > > project, something like Accumulo-Design,
> just
> > > > like
> > > > > > > > >> > accumulo-proxy
> > > > > > > > >> > > > and
> > > > > > > > >> > > > > > > > accumulo-examples. As a separate project,
> it
> > > > would
> > > > > be
> > > > > > > > >> > available
> > > > > > > > >> > > > for
> > > > > > > > >> > > > > > > > collaboration for the community, but remain
> > > > separate
> > > > > > > > >> > > > > > > > from main
> > > > > > > > >> > > > project
> > > > > > > > >> > > > > > and
> > > > > > > > >> > > > > > > > the website to keep current code /
> > > documentation /
> > > > > > > > >> > > > > > > > design
> > > > > > > > >> > clearly
> > > > > > > > >> > > > > > separate
> > > > > > > > >> > > > > > > > from speculative design discussions. As a
> > > > project:
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > - document history would be preserved
> with git
> > > > > > commit
> > > > > > > > >> > history.
> > > > > > > > >> > > > > > > > > - document collaboration could be done
> with
> > > > normal
> > > > > > PR
> > > > > > > > >> > > > submissions /
> > > > > > > > >> > > > > > > > reviews.
> > > > > > > > >> > > > > > > > > - issues could be used to discuss design
> > > > aspects,
> > > > > > > > >> > > > > > > > > capturing
> > > > > > > > >> > the
> > > > > > > > >> > > > > > comment
> > > > > > > > >> > > > > > > > history.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > The biggest downside is that it would be
> yet
> > > > > another
> > > > > > > > >> > > > > > > > > project
> > > > > > > > >> > to
> > > > > > > > >> > > > > > follow /
> > > > > > > > >> > > > > > > > track.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > For me, I think the issue is that we need
> a
> > > > > public,
> > > > > > > > >> > collaborative
> > > > > > > > >> > > > > > space
> > > > > > > > >> > > > > > > > to hold design discussions. Neither the main
> > > > project
> > > > > > or
> > > > > > > > >> > > > > > > > the
> > > > > > > > >> > > > web-site
> > > > > > > > >> > > > > > seem
> > > > > > > > >> > > > > > > > quite appropriate and Confluence seems to
> lack
> > > the
> > > > > > > > >> > collaboration
> > > > > > > > >> > > > that
> > > > > > > > >> > > > > > can
> > > > > > > > >> > > > > > > > be achieved with github.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > We need a space to capture the redesign
> and
> > > > > whatever
> > > > > > > > >> > > > > > > > > we
> > > > > > > > >> > select
> > > > > > > > >> > > > can be
> > > > > > > > >> > > > > > > > made to work - I'm just wondering what
> provides
> > > > the
> > > > > > > > >> > > > > > > > easiest
> > > > > > > > >> > forum
> > > > > > > > >> > > > to
> > > > > > > > >> > > > > > build
> > > > > > > > >> > > > > > > > a collaborative space for the Accumulo
> > > community.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > Ed Coleman
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > On 2023/02/28 16:35:31
> dlmarion@comcast.net
> > > > > wrote:
> > > > > > > > >> > > > > > > > > > Circling back on this issue - I agree
> that
> > > > > > comments
> > > > > > > > >> > > > > > > > > > and
> > > > > > > > >> > such
> > > > > > > > >> > > > make
> > > > > > > > >> > > > > > > > sense for internal design documents. I'm
> going
> > > to
> > > > > > > > >> > > > > > > > create an
> > > > > > > > >> > INFRA
> > > > > > > > >> > > > > > ticket
> > > > > > > > >> > > > > > > > for a cwiki space for Accumulo unless there
> are
> > > > any
> > > > > > > > >> objections.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > -----Original Message-----
> > > > > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16
> PM
> > > > > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github
> wiki in
> > > > > > > asf.yaml?
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > As mentioned, wikis can provide a
> > > streamlined
> > > > > > > > >> > > > > > > > > > collaborative
> > > > > > > > >> > > > editing
> > > > > > > > >> > > > > > > > workflow that's less labor intensive than
> > > > updating a
> > > > > > > > >> website.
> > > > > > > > >> > They
> > > > > > > > >> > > > can
> > > > > > > > >> > > > > > > > promote collaboration by providing specific
> > > > tooling
> > > > > to
> > > > > > > > >> > > > > > > > support
> > > > > > > > >> > > > > > comments,
> > > > > > > > >> > > > > > > > revisions and iteration.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > In terms of preservation, GH wikis act
> just
> > > > like
> > > > > > > > >> > > > > > > > > > any other
> > > > > > > > >> > Git
> > > > > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > > > > git@github.com
> > > > > > > > :
> > > > > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > > > > >> > > > > > > > > > IIRC the pages are just GH flavored
> > > markdown.
> > > > > > There
> > > > > > > > >> > > > > > > > > > are at
> > > > > > > > >> > > > least a
> > > > > > > > >> > > > > > few
> > > > > > > > >> > > > > > > > Apache projects using them.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > However, GH wikis lack some features
> that I
> > > > feel
> > > > > > > > >> > > > > > > > > > are
> > > > > > > > >> > important
> > > > > > > > >> > > > to
> > > > > > > > >> > > > > > > > support collaborative authoring. For
> example,
> > > the
> > > > > > > > >> > > > > > > > ability to
> > > > > > > > >> > > > comment
> > > > > > > > >> > > > > > and
> > > > > > > > >> > > > > > > > discuss specific passages in a document is a
> > > > feature
> > > > > > > > >> > > > > > > > that's
> > > > > > > > >> > > > present in
> > > > > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come
> appreciate
> > > > > this
> > > > > > > > >> > > > > > > > this in
> > > > > > > > >> > my
> > > > > > > > >> > > > google
> > > > > > > > >> > > > > > > > docs and office workflows, so expect that it
> > > would
> > > > > be
> > > > > > > > >> > > > > > > > useful
> > > > > > > > >> > for
> > > > > > > > >> > > > > > Accumulo
> > > > > > > > >> > > > > > > > design discussions too.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith
> > > Turner <
> > > > > > > > >> > > > kturner@apache.org>
> > > > > > > > >> > > > > > > > wrote:
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > > > > documents,
> > > > > > > > >> > > > > > > > > > > I think
> > > > > > > > >> > it
> > > > > > > > >> > > > > > would be
> > > > > > > > >> > > > > > > > > > > less cumbersome than the website and
> we
> > > can
> > > > > > > > >> > > > > > > > > > > always link
> > > > > > > > >> > from
> > > > > > > > >> > > > the
> > > > > > > > >> > > > > > > > > > > website and issues to the wiki. I
> think
> > > its
> > > > > ok
> > > > > > > > >> > > > > > > > > > > to give
> > > > > > > > >> > it a
> > > > > > > > >> > > > try
> > > > > > > > >> > > > > > and
> > > > > > > > >> > > > > > > > > > > abandon it in the future, if abandoned
> > > would
> > > > > > just
> > > > > > > > >> > > > > > > > > > > need to
> > > > > > > > >> > > > > > properly
> > > > > > > > >> > > > > > > > > > > communicate that. The content should
> be
> > > > > > archived
> > > > > > > > >> > > > > > > > > > > in
> > > > > > > > >> > Apache
> > > > > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does
> not do
> > > > that
> > > > > > > > >> > > > > > > > > > > then we
> > > > > > > > >> > should
> > > > > > > > >> > > > > > not use
> > > > > > > > >> > > > > > > > > > > it. If GH wiki is not an option then
> > > could
> > > > > try
> > > > > > > > cwiki.
> > > > > > > > >> > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > I reverted the change. I didn't
> think it
> > > > > would
> > > > > > > > >> > > > > > > > > > > > be a big
> > > > > > > > >> > > > deal,
> > > > > > > > >> > > > > > but
> > > > > > > > >> > > > > > > > if
> > > > > > > > >> > > > > > > > > > > > it
> > > > > > > > >> > > > > > > > > > > requires discussion, then let's
> discuss
> > > it.
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > I'm looking for a place to host
> > > > information
> > > > > > > > >> > > > > > > > > > > > related to
> > > > > > > > >> > > > internal
> > > > > > > > >> > > > > > > > > > > > design
> > > > > > > > >> > > > > > > > > > > discussions. I envision these to be
> living
> > > > > > > > >> > > > > > > > > > > documents that
> > > > > > > > >> > > > will be
> > > > > > > > >> > > > > > > > > > > updated over time as the
> > > > design/implementation
> > > > > > > > >> > progresses and
> > > > > > > > >> > > > > > that
> > > > > > > > >> > > > > > > > > > > other committers will be able to
> comment
> > > on
> > > > > and
> > > > > > > > >> > > > > > > > > > > edit. I
> > > > > > > > >> > don't
> > > > > > > > >> > > > > > feel
> > > > > > > > >> > > > > > > > > > > that the website is the correct place
> for
> > > > this
> > > > > > > > >> because:
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > > > > discussions
> > > > > > > > >> > > > > > > > > > > > should
> > > > > > > > >> > go
> > > > > > > > >> > > > on the
> > > > > > > > >> > > > > > > > > > > > project
> > > > > > > > >> > > > > > > > > > > website.
> > > > > > > > >> > > > > > > > > > > > 2. Changes to the design documents
> > > could
> > > > > not
> > > > > > > > >> > > > > > > > > > > > be seen
> > > > > > > > >> > by
> > > > > > > > >> > > > > > others
> > > > > > > > >> > > > > > > > > > > > right
> > > > > > > > >> > > > > > > > > > > away (IIRC changes to the website are
> > > built
> > > > > and
> > > > > > > > >> > available at
> > > > > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/,
> but
> > > > > human
> > > > > > > > >> > intervention
> > > > > > > > >> > > > is
> > > > > > > > >> > > > > > > > > > > required to publish it at
> > > > > > > > >> https://accumulo.apache.org/).
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > I looked in the INFRA issues and
> other
> > > > > > projects
> > > > > > > > >> > > > > > > > > > > > are
> > > > > > > > >> > using
> > > > > > > > >> > > > the
> > > > > > > > >> > > > > > GH
> > > > > > > > >> > > > > > > > > > > > Wiki
> > > > > > > > >> > > > > > > > > > > feature and I saw no mention of
> backing it
> > > > up
> > > > > or
> > > > > > > > >> > > > > > > > > > > the
> > > > > > > > >> > > > requirement
> > > > > > > > >> > > > > > to
> > > > > > > > >> > > > > > > > do
> > > > > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing
> it
> > > > up?).
> > > > > > It
> > > > > > > > >> > > > > > > > > > > does
> > > > > > > > >> > appear
> > > > > > > > >> > > > > > that we
> > > > > > > > >> > > > > > > > > > > would need an INFRA ticket so that
> they
> > > can
> > > > > > > > >> > > > > > > > > > > modify the
> > > > > > > > >> > GitHub
> > > > > > > > >> > > > > > project
> > > > > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down
> so
> > > > that
> > > > > > > > >> > > > > > > > > > > only
> > > > > > > > >> > > > committers can
> > > > > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not
> > > acceptable,
> > > > > > then
> > > > > > > > >> > > > > > > > > > > I think
> > > > > > > > >> > > > Apache
> > > > > > > > >> > > > > > > > > > > Confluence (
> > > > > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > > > > acceptable
> > > > > > > > >> > > > alternative.
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > > > > >> > > > > > > > > > > > From: Christopher <
> ctubbsii@apache.org>
> > > > > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023
> 4:41
> > > AM
> > > > > > > > >> > > > > > > > > > > > To: accumulo-dev <
> > > dev@accumulo.apache.org
> > > > >
> > > > > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> > > > updated:
> > > > > > > > >> > > > > > > > > > > > Enable
> > > > > > > > >> > Github
> > > > > > > > >> > > > > > wiki in
> > > > > > > > >> > > > > > > > > > > asf.yaml
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > I don't recall a discussion about
> this
> > > > > change,
> > > > > > > > >> > > > > > > > > > > > but I
> > > > > > > > >> > think
> > > > > > > > >> > > > it
> > > > > > > > >> > > > > > goes
> > > > > > > > >> > > > > > > > > > > against previous efforts to make the
> > > website
> > > > > the
> > > > > > > > >> > > > > > > > > > > one
> > > > > > > > >> > > > canonical
> > > > > > > > >> > > > > > > > > > > location for our documentation. I
> don't
> > > even
> > > > > > > > >> > > > > > > > > > > think infra
> > > > > > > > >> > is
> > > > > > > > >> > > > > > backing
> > > > > > > > >> > > > > > > > up
> > > > > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be
> a
> > > > record
> > > > > > of
> > > > > > > > >> > > > > > > > > > > the
> > > > > > > > >> > wiki
> > > > > > > > >> > > > > > contents
> > > > > > > > >> > > > > > > > in
> > > > > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which
> is
> > > > backed
> > > > > > up
> > > > > > > > >> > > > > > > > > > > to
> > > > > > > > >> > GitBox
> > > > > > > > >> > > > and
> > > > > > > > >> > > > > > the
> > > > > > > > >> > > > > > > > > > > issue tracker, which CCs the
> notifications
> > > > > > list).
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > In short, I think this should be
> > > reverted
> > > > > and
> > > > > > > > >> > > > > > > > > > > > we
> > > > > > > > >> > should not
> > > > > > > > >> > > > > > use the
> > > > > > > > >> > > > > > > > > > > GitHub wiki. If we need to store
> documents
> > > > in
> > > > > a
> > > > > > > > >> > > > > > > > > > > version
> > > > > > > > >> > > > > > controlled
> > > > > > > > >> > > > > > > > > > > way, we can store them on the
> website, or
> > > in
> > > > > our
> > > > > > > > >> > project's
> > > > > > > > >> > > > SVN
> > > > > > > > >> > > > > > dev
> > > > > > > > >> > > > > > > > > > > space. The wiki is just another place
> > > people
> > > > > > > > >> > > > > > > > > > > would have
> > > > > > > > >> > to
> > > > > > > > >> > > > > > follow if
> > > > > > > > >> > > > > > > > > > > they want to participate, and I don't
> > > think
> > > > > that
> > > > > > > > >> > > > > > > > > > > serves
> > > > > > > > >> > us.
> > > > > > > > >> > > > > > > > Therefore,
> > > > > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > > > > >> > wrote:
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > > This is an automated email from
> the
> > > ASF
> > > > > > > > >> > > > > > > > > > > > > dual-hosted
> > > > > > > > >> > git
> > > > > > > > >> > > > > > > > repository.
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch
> > > main
> > > > in
> > > > > > > > >> > > > > > > > > > > > > repository
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > > > > >> > > > > > > > > > > > > git
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > > The following commit(s) were
> added to
> > > > > > > > >> > refs/heads/main by
> > > > > > > > >> > > > this
> > > > > > > > >> > > > > > > > push:
> > > > > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github
> wiki
> > > > in
> > > > > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > > > > >> > > > > > ae8a817e7b is
> > > > > > > > >> > > > > > > > > > > > > described below
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > > commit
> > > > > > > > >> > > > > > > > > > > > >
> > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> > > > dlmarion@apache.org>
> > > > > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10
> 2023
> > > > -0500
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > >> > > > > > > > > > > > > ---
> > > > > > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml
> > > index
> > > > > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > > > > >> > > > > > > > > > > > > 100644
> > > > > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > >> > > > > > > > > > > > > - big-data
> > > > > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > > > > >> > > > > > > > > > > > > features:
> > > > > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > > > > >> > > > > > > > > > > > > issues: true
> > > > > > > > >> > > > > > > > > > > > > projects: true
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
Isn't that basically the same as how the website repo works? How would
that be different then?
On Wed, Mar 15, 2023 at 2:55 PM Dave Marion <dm...@gmail.com> wrote:
>
> It looks like we could generate the GH wiki from a folder in the source
> code. This would allow for issues and PRs. Just a thought.
>
> Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
> https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
>
> On Wed, Mar 15, 2023 at 2:16 PM Christopher <ct...@apache.org> wrote:
>
> > It seems like there's a majority consensus of those engaged. No need for a
> > vote, but I think the question about notifications should be addressed
> > first.
> >
> > On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > I'm +1 to using some kind of wiki so if we can't use Confluence then GH
> > > sounds fine to me. Do we need to take a formal vote for using the Github
> > > wiki or is there enough consensus already?
> > >
> > > On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com>
> > wrote:
> > >
> > > > +1 for the GH wiki with major discussions still being fed into, or
> > > > originated on the mailing lists.
> > > >
> > > > As a side question, if there is a lengthy discussion on a GH issue, is
> > it
> > > > standard practice to just recap that in a mailing list message?
> > > > Or is there a more "formal" inclusion process to follow?
> > > >
> > > >
> > > > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org>
> > wrote:
> > > >
> > > > > I don't think the workflow I proposed about using PRs and discussion
> > on
> > > > > tickets, etc. and the accompanying arguments about keeping things
> > > > > consolidated and accessible to potential contributors not
> > participating
> > > > on
> > > > > GitHub, were really challenged at all. However, since I seem to be
> > the
> > > > only
> > > > > one advocating for using the website, to keep things centralized, as
> > > per
> > > > > previous attempts to consolidate documentation, I won't fight the use
> > > of
> > > > > GitHub wiki. But I do want to make it clear that we're proceeding in
> > > that
> > > > > direction under my objection (-0), and that I'm not convinced this is
> > > the
> > > > > best path forward. Hopefully, I will be proven wrong in time.
> > > > >
> > > > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> > > > >
> > > > > > > At this point, I think we should move forward with a GH wiki and
> > > then
> > > > > we
> > > > > > can re-evaluate things once the Apache confluence issue is sorted
> > > out.
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> > > > > >
> > > > > > > I just tried (Wed, 3/15) and still received the same error. I
> > > asked
> > > > on
> > > > > > > the infra slack channel and they replied that they are still
> > > working
> > > > to
> > > > > > > determine what the issue is - signs are pointing to something
> > > inside
> > > > of
> > > > > > > confluence, but no progress.
> > > > > > >
> > > > > > > At this point, I think we should move forward with a GH wiki and
> > > then
> > > > > we
> > > > > > > can re-evaluate things once the Apache confluence issue is sorted
> > > > out.
> > > > > > >
> > > > > > > Ed Coleman
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dave Marion <dm...@gmail.com>
> > > > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > > > To: dev@accumulo.apache.org
> > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > >
> > > > > > > Looking at the Infra slack channel response, one of the responses
> > > in
> > > > > the
> > > > > > > channel said that "it's some sort of db corruption according to
> > > > > > Atlassian".
> > > > > > > Doesn't sound good....
> > > > > > >
> > > > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dmarion18@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > > > unresolved
> > > > > > > > and the only comment on the ticket is one that Ed added two
> > days
> > > > ago
> > > > > > > > requesting an ACCUMULO wiki space.
> > > > > > > >
> > > > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com>
> > wrote:
> > > > > > > >
> > > > > > > >> I do not see any comments in the infa slack channel - so no
> > > > updates
> > > > > > > >> for now.
> > > > > > > >>
> > > > > > > >> -----Original Message-----
> > > > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > > > >> To: dev@accumulo.apache.org
> > > > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > >>
> > > > > > > >> Right, I was just curious if there was any follow-up as I
> > think
> > > Ed
> > > > > > > >> said that it was going to be discussed by the INFRA team
> > > > yesterday.
> > > > > > > >> There is at least one other recent ticket (
> > > > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > > > selfserve
> > > > > > > >> had an issue and the INFRA team created the space manually.
> > > > > > > >>
> > > > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> > > ctubbsii@apache.org>
> > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> > You can track that issue at
> > > > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > > > >> >
> > > > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > > > dmarion18@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >> > >
> > > > > > > >> > > Ed,
> > > > > > > >> > >
> > > > > > > >> > > Any update from INFRA on being able to create confluence
> > > > > pages?
> > > > > > > >> > >
> > > > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > > > ctubbsii@apache.org
> > > > > >
> > > > > > > >> wrote:
> > > > > > > >> > >
> > > > > > > >> > > > We've definitely used the website for more than that. We
> > > use
> > > > > it
> > > > > > > >> > > > to document things for users, help developers know how
> > to
> > > > > > > >> > > > contribute, store drafts of designs, share user stories
> > > via
> > > > > > > >> > > > blogs, do release announcements, and more. There's
> > > > definitely
> > > > > > > >> > > > space on the website to do this kind of thing, if we
> > want
> > > > to.
> > > > > > > >> > > > We've used it that way before. If you only see it as a
> > > place
> > > > > > > >> > > > "for user consumption after everything has been
> > > finalized",
> > > > > > > >> > > > then you're missing out on the other ways we currently
> > use
> > > > the
> > > > > > > >> > > > site, and the ways we've used it in
> > > > > > > >> the past.
> > > > > > > >> > > >
> > > > > > > >> > > > With the website, most of the collaboration would happen
> > > in
> > > > > the
> > > > > > > >> > > > GH issues about proposed designs or changes to designs,
> > > just
> > > > > > > >> > > > like we do today with code or other documentation, which
> > > > > > > >> > > > everybody is used to. I agree it's not as good as Google
> > > > Docs
> > > > > > > >> > > > for on-the-fly comments/annotations, but I don't think
> > > > > > > >> > > > Confluence or Wiki are as good as that either, and
> > Google
> > > > Docs
> > > > > > > isn't really an option...
> > > > > > > >> > > > unless you just want to link to it in the mailing list
> > and
> > > > > > > >> > > > stick to Google Docs from your personal Google account,
> > > > until
> > > > > > > >> > > > it's ready for publication, which would also be fine
> > (any
> > > > > > > >> > > > interested persons can simply request write access by
> > > > replying
> > > > > > > >> > > > to the message where
> > > > > > > >> you shared the link)..
> > > > > > > >> > > >
> > > > > > > >> > > > We are a much smaller project than many others, and we
> > > have
> > > > > > > >> > > > previously suffered from having stuff too spread out.
> > Even
> > > > if
> > > > > > > >> > > > other projects find a separate space valuable for them,
> > > I'm
> > > > > not
> > > > > > > >> > > > sure it's best for the Accumulo project. While I think
> > > it's
> > > > > > > >> > > > useful to examine what other projects do, I do think we
> > > > should
> > > > > > > >> > > > be careful to adopt anything just because others find it
> > > > > > > convenient for them.
> > > > > > > >> > > >
> > > > > > > >> > > > Confluence is my second choice, but with a big gap
> > between
> > > > it
> > > > > > > >> > > > and my first choice.
> > > > > > > >> > > >
> > > > > > > >> > > > On a personal note: I hate using Confluence, because I
> > > think
> > > > > > > >> > > > the navigation is highly unintuitive, as is the
> > > permissions
> > > > > > > >> > > > model, and I don't like the idea of learning yet another
> > > > > > > >> > > > wiki-syntax (though I've read Confluence supports some
> > > > limited
> > > > > > > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I
> > > > also
> > > > > > > >> > > > do not want to set up custom notifications for watching
> > > yet
> > > > > > > >> > > > another space. If we use Confluence, I will probably
> > > > > contribute
> > > > > > > >> > > > very infrequently there because of my frustrations with
> > > > having
> > > > > > > >> > > > used it before. However, that would be my choice, and
> > > should
> > > > > > > >> > > > not be a reason the project chooses one over another.
> > I'm
> > > > > > > >> > > > sharing my personal opinion only because it is
> > influencing
> > > > my
> > > > > > > >> > > > opinion about the website being more accessible, via our
> > > > > > > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder
> > > how
> > > > > > > >> > > > many other potential contributors would feel similarly.
> > > It's
> > > > > > > >> > > > hard to know, since it seems like a lot of this is
> > > > subjective,
> > > > > > > >> > > > and is going to come down to a consensus of personal
> > > > > > > >> preferences.
> > > > > > > >> > > >
> > > > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > > > >> > > > <dm...@gmail.com>
> > > > > > > >> > wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > > I don't see the website as an area where we would have
> > > > > > > >> > > > > collaborative discussions about an idea. For example,
> > > > making
> > > > > > > >> > > > > comments and
> > > > > > > >> > suggestions
> > > > > > > >> > > > on
> > > > > > > >> > > > > a document like you can do in Google Docs. I see the
> > > > website
> > > > > > > >> > > > > as a
> > > > > > > >> > place
> > > > > > > >> > > > > where items are documented for user consumption after
> > > > > > > >> > > > > everything has
> > > > > > > >> > been
> > > > > > > >> > > > > finalized. I'm not trying to create a private
> > discussion
> > > > > > > >> > > > > area, I
> > > > > > > >> > think
> > > > > > > >> > > > > anyone can see the wiki (but I think anonymous
> > comments
> > > > are
> > > > > > > >> > > > > disabled
> > > > > > > >> > due
> > > > > > > >> > > > to
> > > > > > > >> > > > > spam issues). I see no issue with putting
> > > work-in-progress
> > > > > > > >> > > > > documents
> > > > > > > >> > on a
> > > > > > > >> > > > > wiki and referencing them via emails to the dev list.
> > I
> > > > > think
> > > > > > > >> > > > > this is
> > > > > > > >> > > > done
> > > > > > > >> > > > > in a lot of other projects. Non-committers that don't
> > > have
> > > > > > > >> > > > > access to
> > > > > > > >> > the
> > > > > > > >> > > > > wiki and want to make comments, suggestions, and ask
> > > > > > > >> > > > > questions can
> > > > > > > >> > do so
> > > > > > > >> > > > > via the mailing list. I think it's also possible that
> > > > people
> > > > > > > >> > > > > can get confluence accounts (see
> > > > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > > > >> > > > > so if a non-committer wanted to participate they
> > could.
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > > > >> > > > > <ct...@apache.org>
> > > > > > > >> > wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > > > >> > > > > > <dm...@gmail.com>
> > > > > > > >> > > > wrote:
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > I'm opposed to using the website for the reasons I
> > > > > > > >> > > > > > > specified
> > > > > > > >> > > > earlier, so
> > > > > > > >> > > > > > it
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Your reasons that I saw were:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > 1. I don't think internal design discussions
> > should
> > > go
> > > > > on
> > > > > > > >> > > > > > > the
> > > > > > > >> > project
> > > > > > > >> > > > > > website.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > That doesn't look to me like a reason. That appears
> > to
> > > > > just
> > > > > > > >> > > > > > be
> > > > > > > >> > stating
> > > > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > 2. Changes to the design documents could not be
> > seen
> > > > by
> > > > > > > >> > > > > > > others
> > > > > > > >> > right
> > > > > > > >> > > > > > away (IIRC changes to the website are built and
> > > > available
> > > > > > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > > > > > >> > > > > > intervention is
> > > > > > > >> > > > required
> > > > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > What do you mean by "others" here? Do you mean
> > > "users",
> > > > as
> > > > > > > >> > > > > > opposed
> > > > > > > >> > to
> > > > > > > >> > > > > > "developers/contributors"? The ASF draws a
> > distinction
> > > > > > > >> > > > > > between "developers/contributors" and "users" as it
> > > > > > > >> > > > > > pertains to official releases. Releases are intended
> > > to
> > > > be
> > > > > > > >> > > > > > consumed by users, and pre-release stuff is intended
> > > to
> > > > be
> > > > > > > >> > > > > > collaborative, open to all potential
> > > > > > > >> > > > > > developers/contributors. Very very rarely are things
> > > > > > > >> > > > > > reserved exclusively for committers. We don't even
> > > have
> > > > a
> > > > > > > >> > > > > > private committers space (the private mailing list
> > is
> > > > > > > >> > > > > > PMC-private, not committer-private). Having a
> > > > distinction
> > > > > > > >> > > > > > between users and
> > > > > > > >> > developers
> > > > > > > >> > > > > > doesn't mean we can't publish things on the
> > website...
> > > > it
> > > > > > > >> > > > > > just
> > > > > > > >> > means
> > > > > > > >> > > > > > that we should be careful about how we do it, which
> > is
> > > > the
> > > > > > > >> > > > > > same
> > > > > > > >> > care
> > > > > > > >> > > > > > we should take regardless of where we put it.
> > > > > Specifically,
> > > > > > > >> > > > > > the
> > > > > > > >> > care
> > > > > > > >> > > > > > we need to take is to avoid marketing pre-release
> > > > content
> > > > > > > >> > > > > > to
> > > > > > > >> users.
> > > > > > > >> > > > > > One way we can exercise this care for content on our
> > > > > > > >> > > > > > website is
> > > > > > > >> > that
> > > > > > > >> > > > > > we can avoid sharing these unpolished designs by
> > > simply
> > > > > not
> > > > > > > >> > > > > > linking them on the site, or by placing them in an
> > > area
> > > > > > > >> > > > > > that is clearly
> > > > > > > >> > marked
> > > > > > > >> > > > > > as intended for devs. But, we have no similar
> > > > distinction
> > > > > > > >> > > > > > between committers and non-committer devs for which
> > we
> > > > > > > >> > > > > > should avoid sharing pre-release content under
> > > > > development.
> > > > > > > >> > > > > > In fact, it is the
> > > > > > > >> > opposite...
> > > > > > > >> > > > > > we should be developing openly so as to allow room
> > for
> > > > > > > >> > non-committers
> > > > > > > >> > > > > > to become committers through participation in
> > > > development
> > > > > > > >> > activities.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > As for the staging/publication of the website,
> > that's
> > > > just
> > > > > > > >> > > > > > a
> > > > > > > >> > mechanic
> > > > > > > >> > > > > > for verifying the website isn't broken before we
> > serve
> > > > it.
> > > > > > > >> > > > > > It's
> > > > > > > >> > not a
> > > > > > > >> > > > > > mechanism for keeping things internal vs. shared and
> > > > > > > >> > > > > > doesn't have anything to do with the separation
> > > between
> > > > > > > >> > > > > > devs and users. We
> > > > > > > >> > already
> > > > > > > >> > > > > > publish Draft contents to the website, as well as
> > > > > > > >> > developer-specific
> > > > > > > >> > > > > > documentation not intended for users.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > We've even specifically published work-in-progress
> > > > design
> > > > > > > >> > > > > > documents there, of the same type that seems to be
> > the
> > > > > > > >> > > > > > basis of this conversation (
> > > > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > > > >> > I
> > > > > > > >> > > > > > would strongly prefer us to continue to do it this
> > > way,
> > > > > > > >> > > > > > rather than create a new space, and have these kinds
> > > of
> > > > > > > >> > > > > > things scattered in multiple places.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > If, on the other hand, you intend to say that these
> > > > should
> > > > > > > >> > > > > > be
> > > > > > > >> > private
> > > > > > > >> > > > > > because they aren't ready for other potential
> > > > > contributors,
> > > > > > > >> > > > > > then I would argue that we're an openly developed
> > > > > project...
> > > > > > > >> > > > > > if something isn't ready to be shared with other
> > > > potential
> > > > > > > >> > > > > > contributors / developers, such that you want to
> > keep
> > > it
> > > > > > > >> > > > > > internal to existing committers, then it's not ready
> > > to
> > > > be
> > > > > > > >> > > > > > contributed to the project at all... because we
> > don't
> > > > > > > >> > > > > > restrict collaboration to only existing committers.
> > > That
> > > > > > > >> > > > > > would prevent others from participating and
> > > > > > > >> > earning
> > > > > > > >> > > > > > the merit to become committers, and that's not
> > > something
> > > > > we
> > > > > > > >> > > > > > should
> > > > > > > >> > be
> > > > > > > >> > > > > > doing. Anything that is okay to share with existing
> > > > > > > >> > > > > > committers
> > > > > > > >> > should
> > > > > > > >> > > > > > be okay to share to other potential contributors who
> > > > want
> > > > > > > >> > > > > > to participate, and should be done in a space that
> > > > allows
> > > > > > > >> > > > > > them to do that. The website is a perfect space for
> > > > that,
> > > > > > > >> > > > > > and has everything
> > > > > > > >> > we
> > > > > > > >> > > > > > need. I'm actually not sure about Confluence... I
> > > > suspect
> > > > > > > >> > > > > > non-committers wouldn't be able to participate there
> > > > > > > >> > > > > > because they probably can't get accounts for it.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > looks like we need to
> > > > > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious
> > how
> > > > > much
> > > > > > > >> > > > > > > we
> > > > > > > >> > need to
> > > > > > > >> > > > use
> > > > > > > >> > > > > > > the mailing list during
> > > > > > > >> > > > > > > the design phase. We can announce meeting
> > > dates/times
> > > > on
> > > > > > > >> > > > > > > the
> > > > > > > >> > mailing
> > > > > > > >> > > > list
> > > > > > > >> > > > > > > and post links to
> > > > > > > >> > > > > > > meeting notes in Confluence. Ultimately, decisions
> > > > made
> > > > > > > >> > > > > > > by the
> > > > > > > >> > people
> > > > > > > >> > > > > > that
> > > > > > > >> > > > > > > want to be involved
> > > > > > > >> > > > > > > will turn into pull requests against the codebase
> > > > which
> > > > > > > >> > comitters can
> > > > > > > >> > > > > > weigh
> > > > > > > >> > > > > > > in on. When you say,
> > > > > > > >> > > > > > > "... but decisions about those would still need to
> > > be
> > > > > > > >> > > > > > > done on the
> > > > > > > >> > > > mailing
> > > > > > > >> > > > > > > list." Are you saying that we need to discuss
> > every
> > > > > > > >> > > > > > > single design decision on the mailing
> > > > > > > >> > list?
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Yes and no. I am saying that decisions need to
> > happen
> > > on
> > > > > > > >> > > > > > the
> > > > > > > >> > mailing
> > > > > > > >> > > > > > list, but I agree with you that this can be
> > satisfied
> > > > > > > >> > > > > > through pull requests. I just wanted to emphasize
> > that
> > > > > > > >> > > > > > regardless of where we do that pre-decision
> > > > collaboration,
> > > > > > > >> > > > > > that collaboration should not be misconstrued as a
> > > > > decision
> > > > > > > >> > > > > > to
> > > > > > > >> accept those ideas into the project.
> > > > > > > >> > The
> > > > > > > >> > > > > > decision occurs during the PR or other activity that
> > > > > > > >> > > > > > interfaces
> > > > > > > >> > with
> > > > > > > >> > > > > > the mailing list, subsequent to the collaboration in
> > > the
> > > > > > > >> > design/idea
> > > > > > > >> > > > > > phase.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > As for the pre-decision collaboration space we're
> > > > > > > >> > > > > > discussing, I
> > > > > > > >> > just
> > > > > > > >> > > > > > want to be careful that we're not creating such a
> > > space
> > > > in
> > > > > > > >> > > > > > an exclusionary way that allows only existing
> > > committers
> > > > > to
> > > > > > > >> > participate,
> > > > > > > >> > > > > > that excludes other potential contributors. This is
> > > > still
> > > > > > > >> > > > > > an openly-developed project, and we should
> > collaborate
> > > > in
> > > > > a
> > > > > > > >> > > > > > space
> > > > > > > >> > that is
> > > > > > > >> > > > > > not exclusive to existing committers, but open to
> > > > > > > >> > > > > > non-committer contributors and potential
> > contributors
> > > as
> > > > > > well.
> > > > > > > >> > > > > > So, while we may
> > > > > > > >> > want
> > > > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > > > >> > > > > > consumption (an important separation that relates to
> > > > > > > >> > > > > > official ASF releases), we
> > > > > > > >> > should
> > > > > > > >> > > > > > not be drawing a line between committer-devs as
> > > > "internal"
> > > > > > > >> > > > > > and contributor-devs as "external". The website,
> > with
> > > > its
> > > > > > > >> > > > > > own issue tracker, the ability to render markdown,
> > do
> > > > > > > >> > > > > > reviews, and collaboratively edit, seems like the
> > > ideal
> > > > > > > >> > > > > > place to me. We've used
> > > > > > > >> > it
> > > > > > > >> > > > > > before for the same purpose, and I think we should
> > > > > continue
> > > > > > > >> > > > > > to do
> > > > > > > >> > so.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > > > >> > >
> > > > > > > >> > > > wrote:
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > > So, I agree a space would be helpful. Although
> > > it's
> > > > > old
> > > > > > > >> > > > > > > > school
> > > > > > > >> > and
> > > > > > > >> > > > > > > > inconvenient, the mailing list is the canonical
> > > > place
> > > > > > > >> > > > > > > > for
> > > > > > > >> > > > discussion.
> > > > > > > >> > > > > > > > We currently use GitHub issues a lot, but that's
> > > > > copied
> > > > > > > >> > > > > > > > to a
> > > > > > > >> > > > mailing
> > > > > > > >> > > > > > > > list (as is our old JIRA space), so if people
> > want
> > > > to
> > > > > > > >> > participate
> > > > > > > >> > > > > > > > without a GitHub account, they can still do
> > that.
> > > > > There
> > > > > > > >> > > > > > > > are
> > > > > > > >> > certain
> > > > > > > >> > > > > > > > options that are perhaps less convenient, such
> > as
> > > > just
> > > > > > > >> > > > > > > > using
> > > > > > > >> > the
> > > > > > > >> > > > > > > > mailing list and our dev SVN space, but still
> > more
> > > > > > > >> > > > > > > > appropriate
> > > > > > > >> > than
> > > > > > > >> > > > > > > > options that would be less ubiquitous for
> > > potential
> > > > > > > >> > participants.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > > > > > > >> > > > > > > > storing,
> > > > > > > >> > editing,
> > > > > > > >> > > > and
> > > > > > > >> > > > > > > > collaborating on shared documents, but decisions
> > > > about
> > > > > > > >> > > > > > > > those
> > > > > > > >> > would
> > > > > > > >> > > > > > > > still need to be done on the mailing list. If I
> > > > > > > >> > > > > > > > remember
> > > > > > > >> > > > correctly, we
> > > > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > > > >> > > > favor
> > > > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > > > >> > > > > > > > mis-remembering, but
> > > > > > > >> > I
> > > > > > > >> > > > think
> > > > > > > >> > > > > > > > this is the case. It might explain why you can't
> > > > > create
> > > > > > > >> > > > > > > > a
> > > > > > > >> > > > Confluence
> > > > > > > >> > > > > > > > space.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > My preference would be to just use the website.
> > I
> > > > > think
> > > > > > > >> > > > > > > > it's
> > > > > > > >> > fine
> > > > > > > >> > > > to
> > > > > > > >> > > > > > > > have a dev / design area of the website, and we
> > > can
> > > > > > > >> > > > > > > > discuss on
> > > > > > > >> > > > GitHub
> > > > > > > >> > > > > > > > issues for the accumulo-website repo. That is a
> > > bit
> > > > > > > >> > > > > > > > less
> > > > > > > >> > convenient
> > > > > > > >> > > > > > > > than Confluence if it's used heavily, but it's
> > > more
> > > > > > > >> > > > > > > > convenient
> > > > > > > >> > in
> > > > > > > >> > > > the
> > > > > > > >> > > > > > > > sense that it's more accessible and fits more in
> > > > line
> > > > > > > >> > > > > > > > with our
> > > > > > > >> > > > current
> > > > > > > >> > > > > > > > mode of operation. Plus, when a document is
> > final,
> > > > > it's
> > > > > > > >> > > > > > > > easy to
> > > > > > > >> > > > link
> > > > > > > >> > > > > > > > to from our documentation, without making users
> > > jump
> > > > > to
> > > > > > > >> > > > > > > > another service to view docs.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > I would be opposed to using GitHub wiki or a new
> > > git
> > > > > > repo.
> > > > > > > >> > > > > > > > We
> > > > > > > >> > have
> > > > > > > >> > > > > > > > enough repos. Although it seems like they are
> > > free,
> > > > > > > >> > > > > > > > there is
> > > > > > > >> > still
> > > > > > > >> > > > a
> > > > > > > >> > > > > > > > lot of boilerplate work to maintain them, from
> > > > > managing
> > > > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md,
> > etc.,
> > > to
> > > > > > > >> > .asf.yaml, to
> > > > > > > >> > > > > > > > README, to keeping copyright dates updated in
> > the
> > > > > > > >> > > > > > > > NOTICE file,
> > > > > > > >> > and
> > > > > > > >> > > > > > > > more.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > In summary, my preference:
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on
> > GH
> > > > > > > >> > > > > > > > issues and
> > > > > > > >> > > > mailing
> > > > > > > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss
> > > on
> > > > > > > >> > > > > > > > mailing list (prefer over other
> > > > > > > >> > options,
> > > > > > > >> > > > but
> > > > > > > >> > > > > > > > not a fan)
> > > > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list
> > (strongly
> > > > > > > >> > > > > > > > prefer not
> > > > > > > >> > to use
> > > > > > > >> > > > > > this
> > > > > > > >> > > > > > > > option)
> > > > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> > > mailing
> > > > > > > >> > > > > > > > list
> > > > > > > >> > (strongly
> > > > > > > >> > > > > > > > prefer not to use this option)
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > > > >> > edcoleman@apache.org>
> > > > > > > >> > > > > > wrote:
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > Currently, asf cannot create new wiki's
> > because
> > > > of a
> > > > > > > >> > Confluence
> > > > > > > >> > > > > > issue (
> > > > > > > >> > > > > > > >
> > https://issues.apache.org/jira/browse/INFRA-24291
> > > )
> > > > I
> > > > > > > >> > > > > > > > chatted
> > > > > > > >> > with
> > > > > > > >> > > > > > infra
> > > > > > > >> > > > > > > > and in response they created that issue.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > To expand on this discussion, I would like to
> > > toss
> > > > > > > >> > > > > > > > > out
> > > > > > > >> > another
> > > > > > > >> > > > > > > > alternative to discuss / explore. What if we
> > > used a
> > > > > > > >> > > > > > > > separate
> > > > > > > >> > > > GitHub
> > > > > > > >> > > > > > > > project, something like Accumulo-Design, just
> > > like
> > > > > > > >> > accumulo-proxy
> > > > > > > >> > > > and
> > > > > > > >> > > > > > > > accumulo-examples. As a separate project, it
> > > would
> > > > be
> > > > > > > >> > available
> > > > > > > >> > > > for
> > > > > > > >> > > > > > > > collaboration for the community, but remain
> > > separate
> > > > > > > >> > > > > > > > from main
> > > > > > > >> > > > project
> > > > > > > >> > > > > > and
> > > > > > > >> > > > > > > > the website to keep current code /
> > documentation /
> > > > > > > >> > > > > > > > design
> > > > > > > >> > clearly
> > > > > > > >> > > > > > separate
> > > > > > > >> > > > > > > > from speculative design discussions. As a
> > > project:
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > - document history would be preserved with git
> > > > > commit
> > > > > > > >> > history.
> > > > > > > >> > > > > > > > > - document collaboration could be done with
> > > normal
> > > > > PR
> > > > > > > >> > > > submissions /
> > > > > > > >> > > > > > > > reviews.
> > > > > > > >> > > > > > > > > - issues could be used to discuss design
> > > aspects,
> > > > > > > >> > > > > > > > > capturing
> > > > > > > >> > the
> > > > > > > >> > > > > > comment
> > > > > > > >> > > > > > > > history.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > The biggest downside is that it would be yet
> > > > another
> > > > > > > >> > > > > > > > > project
> > > > > > > >> > to
> > > > > > > >> > > > > > follow /
> > > > > > > >> > > > > > > > track.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > For me, I think the issue is that we need a
> > > > public,
> > > > > > > >> > collaborative
> > > > > > > >> > > > > > space
> > > > > > > >> > > > > > > > to hold design discussions. Neither the main
> > > project
> > > > > or
> > > > > > > >> > > > > > > > the
> > > > > > > >> > > > web-site
> > > > > > > >> > > > > > seem
> > > > > > > >> > > > > > > > quite appropriate and Confluence seems to lack
> > the
> > > > > > > >> > collaboration
> > > > > > > >> > > > that
> > > > > > > >> > > > > > can
> > > > > > > >> > > > > > > > be achieved with github.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > We need a space to capture the redesign and
> > > > whatever
> > > > > > > >> > > > > > > > > we
> > > > > > > >> > select
> > > > > > > >> > > > can be
> > > > > > > >> > > > > > > > made to work - I'm just wondering what provides
> > > the
> > > > > > > >> > > > > > > > easiest
> > > > > > > >> > forum
> > > > > > > >> > > > to
> > > > > > > >> > > > > > build
> > > > > > > >> > > > > > > > a collaborative space for the Accumulo
> > community.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > Ed Coleman
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net
> > > > wrote:
> > > > > > > >> > > > > > > > > > Circling back on this issue - I agree that
> > > > > comments
> > > > > > > >> > > > > > > > > > and
> > > > > > > >> > such
> > > > > > > >> > > > make
> > > > > > > >> > > > > > > > sense for internal design documents. I'm going
> > to
> > > > > > > >> > > > > > > > create an
> > > > > > > >> > INFRA
> > > > > > > >> > > > > > ticket
> > > > > > > >> > > > > > > > for a cwiki space for Accumulo unless there are
> > > any
> > > > > > > >> objections.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > -----Original Message-----
> > > > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> > > > > > asf.yaml?
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > As mentioned, wikis can provide a
> > streamlined
> > > > > > > >> > > > > > > > > > collaborative
> > > > > > > >> > > > editing
> > > > > > > >> > > > > > > > workflow that's less labor intensive than
> > > updating a
> > > > > > > >> website.
> > > > > > > >> > They
> > > > > > > >> > > > can
> > > > > > > >> > > > > > > > promote collaboration by providing specific
> > > tooling
> > > > to
> > > > > > > >> > > > > > > > support
> > > > > > > >> > > > > > comments,
> > > > > > > >> > > > > > > > revisions and iteration.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > In terms of preservation, GH wikis act just
> > > like
> > > > > > > >> > > > > > > > > > any other
> > > > > > > >> > Git
> > > > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > > > git@github.com
> > > > > > > :
> > > > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > > > >> > > > > > > > > > IIRC the pages are just GH flavored
> > markdown.
> > > > > There
> > > > > > > >> > > > > > > > > > are at
> > > > > > > >> > > > least a
> > > > > > > >> > > > > > few
> > > > > > > >> > > > > > > > Apache projects using them.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > However, GH wikis lack some features that I
> > > feel
> > > > > > > >> > > > > > > > > > are
> > > > > > > >> > important
> > > > > > > >> > > > to
> > > > > > > >> > > > > > > > support collaborative authoring. For example,
> > the
> > > > > > > >> > > > > > > > ability to
> > > > > > > >> > > > comment
> > > > > > > >> > > > > > and
> > > > > > > >> > > > > > > > discuss specific passages in a document is a
> > > feature
> > > > > > > >> > > > > > > > that's
> > > > > > > >> > > > present in
> > > > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate
> > > > this
> > > > > > > >> > > > > > > > this in
> > > > > > > >> > my
> > > > > > > >> > > > google
> > > > > > > >> > > > > > > > docs and office workflows, so expect that it
> > would
> > > > be
> > > > > > > >> > > > > > > > useful
> > > > > > > >> > for
> > > > > > > >> > > > > > Accumulo
> > > > > > > >> > > > > > > > design discussions too.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith
> > Turner <
> > > > > > > >> > > > kturner@apache.org>
> > > > > > > >> > > > > > > > wrote:
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > > > documents,
> > > > > > > >> > > > > > > > > > > I think
> > > > > > > >> > it
> > > > > > > >> > > > > > would be
> > > > > > > >> > > > > > > > > > > less cumbersome than the website and we
> > can
> > > > > > > >> > > > > > > > > > > always link
> > > > > > > >> > from
> > > > > > > >> > > > the
> > > > > > > >> > > > > > > > > > > website and issues to the wiki. I think
> > its
> > > > ok
> > > > > > > >> > > > > > > > > > > to give
> > > > > > > >> > it a
> > > > > > > >> > > > try
> > > > > > > >> > > > > > and
> > > > > > > >> > > > > > > > > > > abandon it in the future, if abandoned
> > would
> > > > > just
> > > > > > > >> > > > > > > > > > > need to
> > > > > > > >> > > > > > properly
> > > > > > > >> > > > > > > > > > > communicate that. The content should be
> > > > > archived
> > > > > > > >> > > > > > > > > > > in
> > > > > > > >> > Apache
> > > > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does not do
> > > that
> > > > > > > >> > > > > > > > > > > then we
> > > > > > > >> > should
> > > > > > > >> > > > > > not use
> > > > > > > >> > > > > > > > > > > it. If GH wiki is not an option then
> > could
> > > > try
> > > > > > > cwiki.
> > > > > > > >> > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > > > >> > > > wrote:
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > I reverted the change. I didn't think it
> > > > would
> > > > > > > >> > > > > > > > > > > > be a big
> > > > > > > >> > > > deal,
> > > > > > > >> > > > > > but
> > > > > > > >> > > > > > > > if
> > > > > > > >> > > > > > > > > > > > it
> > > > > > > >> > > > > > > > > > > requires discussion, then let's discuss
> > it.
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > I'm looking for a place to host
> > > information
> > > > > > > >> > > > > > > > > > > > related to
> > > > > > > >> > > > internal
> > > > > > > >> > > > > > > > > > > > design
> > > > > > > >> > > > > > > > > > > discussions. I envision these to be living
> > > > > > > >> > > > > > > > > > > documents that
> > > > > > > >> > > > will be
> > > > > > > >> > > > > > > > > > > updated over time as the
> > > design/implementation
> > > > > > > >> > progresses and
> > > > > > > >> > > > > > that
> > > > > > > >> > > > > > > > > > > other committers will be able to comment
> > on
> > > > and
> > > > > > > >> > > > > > > > > > > edit. I
> > > > > > > >> > don't
> > > > > > > >> > > > > > feel
> > > > > > > >> > > > > > > > > > > that the website is the correct place for
> > > this
> > > > > > > >> because:
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > > > discussions
> > > > > > > >> > > > > > > > > > > > should
> > > > > > > >> > go
> > > > > > > >> > > > on the
> > > > > > > >> > > > > > > > > > > > project
> > > > > > > >> > > > > > > > > > > website.
> > > > > > > >> > > > > > > > > > > > 2. Changes to the design documents
> > could
> > > > not
> > > > > > > >> > > > > > > > > > > > be seen
> > > > > > > >> > by
> > > > > > > >> > > > > > others
> > > > > > > >> > > > > > > > > > > > right
> > > > > > > >> > > > > > > > > > > away (IIRC changes to the website are
> > built
> > > > and
> > > > > > > >> > available at
> > > > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but
> > > > human
> > > > > > > >> > intervention
> > > > > > > >> > > > is
> > > > > > > >> > > > > > > > > > > required to publish it at
> > > > > > > >> https://accumulo.apache.org/).
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > I looked in the INFRA issues and other
> > > > > projects
> > > > > > > >> > > > > > > > > > > > are
> > > > > > > >> > using
> > > > > > > >> > > > the
> > > > > > > >> > > > > > GH
> > > > > > > >> > > > > > > > > > > > Wiki
> > > > > > > >> > > > > > > > > > > feature and I saw no mention of backing it
> > > up
> > > > or
> > > > > > > >> > > > > > > > > > > the
> > > > > > > >> > > > requirement
> > > > > > > >> > > > > > to
> > > > > > > >> > > > > > > > do
> > > > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing it
> > > up?).
> > > > > It
> > > > > > > >> > > > > > > > > > > does
> > > > > > > >> > appear
> > > > > > > >> > > > > > that we
> > > > > > > >> > > > > > > > > > > would need an INFRA ticket so that they
> > can
> > > > > > > >> > > > > > > > > > > modify the
> > > > > > > >> > GitHub
> > > > > > > >> > > > > > project
> > > > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down so
> > > that
> > > > > > > >> > > > > > > > > > > only
> > > > > > > >> > > > committers can
> > > > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not
> > acceptable,
> > > > > then
> > > > > > > >> > > > > > > > > > > I think
> > > > > > > >> > > > Apache
> > > > > > > >> > > > > > > > > > > Confluence (
> > > > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > > > acceptable
> > > > > > > >> > > > alternative.
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > > > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41
> > AM
> > > > > > > >> > > > > > > > > > > > To: accumulo-dev <
> > dev@accumulo.apache.org
> > > >
> > > > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> > > updated:
> > > > > > > >> > > > > > > > > > > > Enable
> > > > > > > >> > Github
> > > > > > > >> > > > > > wiki in
> > > > > > > >> > > > > > > > > > > asf.yaml
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > I don't recall a discussion about this
> > > > change,
> > > > > > > >> > > > > > > > > > > > but I
> > > > > > > >> > think
> > > > > > > >> > > > it
> > > > > > > >> > > > > > goes
> > > > > > > >> > > > > > > > > > > against previous efforts to make the
> > website
> > > > the
> > > > > > > >> > > > > > > > > > > one
> > > > > > > >> > > > canonical
> > > > > > > >> > > > > > > > > > > location for our documentation. I don't
> > even
> > > > > > > >> > > > > > > > > > > think infra
> > > > > > > >> > is
> > > > > > > >> > > > > > backing
> > > > > > > >> > > > > > > > up
> > > > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a
> > > record
> > > > > of
> > > > > > > >> > > > > > > > > > > the
> > > > > > > >> > wiki
> > > > > > > >> > > > > > contents
> > > > > > > >> > > > > > > > in
> > > > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is
> > > backed
> > > > > up
> > > > > > > >> > > > > > > > > > > to
> > > > > > > >> > GitBox
> > > > > > > >> > > > and
> > > > > > > >> > > > > > the
> > > > > > > >> > > > > > > > > > > issue tracker, which CCs the notifications
> > > > > list).
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > In short, I think this should be
> > reverted
> > > > and
> > > > > > > >> > > > > > > > > > > > we
> > > > > > > >> > should not
> > > > > > > >> > > > > > use the
> > > > > > > >> > > > > > > > > > > GitHub wiki. If we need to store documents
> > > in
> > > > a
> > > > > > > >> > > > > > > > > > > version
> > > > > > > >> > > > > > controlled
> > > > > > > >> > > > > > > > > > > way, we can store them on the website, or
> > in
> > > > our
> > > > > > > >> > project's
> > > > > > > >> > > > SVN
> > > > > > > >> > > > > > dev
> > > > > > > >> > > > > > > > > > > space. The wiki is just another place
> > people
> > > > > > > >> > > > > > > > > > > would have
> > > > > > > >> > to
> > > > > > > >> > > > > > follow if
> > > > > > > >> > > > > > > > > > > they want to participate, and I don't
> > think
> > > > that
> > > > > > > >> > > > > > > > > > > serves
> > > > > > > >> > us.
> > > > > > > >> > > > > > > > Therefore,
> > > > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > > > >> > wrote:
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > > This is an automated email from the
> > ASF
> > > > > > > >> > > > > > > > > > > > > dual-hosted
> > > > > > > >> > git
> > > > > > > >> > > > > > > > repository.
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch
> > main
> > > in
> > > > > > > >> > > > > > > > > > > > > repository
> > > > > > > >> > > > > > > > > > > > >
> > > > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > > > >> > > > > > > > > > > > > git
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > > The following commit(s) were added to
> > > > > > > >> > refs/heads/main by
> > > > > > > >> > > > this
> > > > > > > >> > > > > > > > push:
> > > > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki
> > > in
> > > > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > > > >> > > > > > ae8a817e7b is
> > > > > > > >> > > > > > > > > > > > > described below
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > > commit
> > > > > > > >> > > > > > > > > > > > >
> > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> > > dlmarion@apache.org>
> > > > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023
> > > -0500
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > >> > > > > > > > > > > > > ---
> > > > > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml
> > index
> > > > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > > > >> > > > > > > > > > > > > 100644
> > > > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > >> > > > > > > > > > > > > - big-data
> > > > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > > > >> > > > > > > > > > > > > features:
> > > > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > > > >> > > > > > > > > > > > > issues: true
> > > > > > > >> > > > > > > > > > > > > projects: true
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > > >
> > > > > > > >> > > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
It looks like we could generate the GH wiki from a folder in the source
code. This would allow for issues and PRs. Just a thought.
Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
On Wed, Mar 15, 2023 at 2:16 PM Christopher <ct...@apache.org> wrote:
> It seems like there's a majority consensus of those engaged. No need for a
> vote, but I think the question about notifications should be addressed
> first.
>
> On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > I'm +1 to using some kind of wiki so if we can't use Confluence then GH
> > sounds fine to me. Do we need to take a formal vote for using the Github
> > wiki or is there enough consensus already?
> >
> > On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com>
> wrote:
> >
> > > +1 for the GH wiki with major discussions still being fed into, or
> > > originated on the mailing lists.
> > >
> > > As a side question, if there is a lengthy discussion on a GH issue, is
> it
> > > standard practice to just recap that in a mailing list message?
> > > Or is there a more "formal" inclusion process to follow?
> > >
> > >
> > > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org>
> wrote:
> > >
> > > > I don't think the workflow I proposed about using PRs and discussion
> on
> > > > tickets, etc. and the accompanying arguments about keeping things
> > > > consolidated and accessible to potential contributors not
> participating
> > > on
> > > > GitHub, were really challenged at all. However, since I seem to be
> the
> > > only
> > > > one advocating for using the website, to keep things centralized, as
> > per
> > > > previous attempts to consolidate documentation, I won't fight the use
> > of
> > > > GitHub wiki. But I do want to make it clear that we're proceeding in
> > that
> > > > direction under my objection (-0), and that I'm not convinced this is
> > the
> > > > best path forward. Hopefully, I will be proven wrong in time.
> > > >
> > > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> > > >
> > > > > > At this point, I think we should move forward with a GH wiki and
> > then
> > > > we
> > > > > can re-evaluate things once the Apache confluence issue is sorted
> > out.
> > > > >
> > > > > Agreed.
> > > > >
> > > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> > > > >
> > > > > > I just tried (Wed, 3/15) and still received the same error. I
> > asked
> > > on
> > > > > > the infra slack channel and they replied that they are still
> > working
> > > to
> > > > > > determine what the issue is - signs are pointing to something
> > inside
> > > of
> > > > > > confluence, but no progress.
> > > > > >
> > > > > > At this point, I think we should move forward with a GH wiki and
> > then
> > > > we
> > > > > > can re-evaluate things once the Apache confluence issue is sorted
> > > out.
> > > > > >
> > > > > > Ed Coleman
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dave Marion <dm...@gmail.com>
> > > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > > To: dev@accumulo.apache.org
> > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > >
> > > > > > Looking at the Infra slack channel response, one of the responses
> > in
> > > > the
> > > > > > channel said that "it's some sort of db corruption according to
> > > > > Atlassian".
> > > > > > Doesn't sound good....
> > > > > >
> > > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dmarion18@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > > unresolved
> > > > > > > and the only comment on the ticket is one that Ed added two
> days
> > > ago
> > > > > > > requesting an ACCUMULO wiki space.
> > > > > > >
> > > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com>
> wrote:
> > > > > > >
> > > > > > >> I do not see any comments in the infa slack channel - so no
> > > updates
> > > > > > >> for now.
> > > > > > >>
> > > > > > >> -----Original Message-----
> > > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > > >> To: dev@accumulo.apache.org
> > > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > >>
> > > > > > >> Right, I was just curious if there was any follow-up as I
> think
> > Ed
> > > > > > >> said that it was going to be discussed by the INFRA team
> > > yesterday.
> > > > > > >> There is at least one other recent ticket (
> > > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > > selfserve
> > > > > > >> had an issue and the INFRA team created the space manually.
> > > > > > >>
> > > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> > ctubbsii@apache.org>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> > You can track that issue at
> > > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > > >> >
> > > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > > dmarion18@gmail.com>
> > > > > > >> wrote:
> > > > > > >> > >
> > > > > > >> > > Ed,
> > > > > > >> > >
> > > > > > >> > > Any update from INFRA on being able to create confluence
> > > > pages?
> > > > > > >> > >
> > > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > > ctubbsii@apache.org
> > > > >
> > > > > > >> wrote:
> > > > > > >> > >
> > > > > > >> > > > We've definitely used the website for more than that. We
> > use
> > > > it
> > > > > > >> > > > to document things for users, help developers know how
> to
> > > > > > >> > > > contribute, store drafts of designs, share user stories
> > via
> > > > > > >> > > > blogs, do release announcements, and more. There's
> > > definitely
> > > > > > >> > > > space on the website to do this kind of thing, if we
> want
> > > to.
> > > > > > >> > > > We've used it that way before. If you only see it as a
> > place
> > > > > > >> > > > "for user consumption after everything has been
> > finalized",
> > > > > > >> > > > then you're missing out on the other ways we currently
> use
> > > the
> > > > > > >> > > > site, and the ways we've used it in
> > > > > > >> the past.
> > > > > > >> > > >
> > > > > > >> > > > With the website, most of the collaboration would happen
> > in
> > > > the
> > > > > > >> > > > GH issues about proposed designs or changes to designs,
> > just
> > > > > > >> > > > like we do today with code or other documentation, which
> > > > > > >> > > > everybody is used to. I agree it's not as good as Google
> > > Docs
> > > > > > >> > > > for on-the-fly comments/annotations, but I don't think
> > > > > > >> > > > Confluence or Wiki are as good as that either, and
> Google
> > > Docs
> > > > > > isn't really an option...
> > > > > > >> > > > unless you just want to link to it in the mailing list
> and
> > > > > > >> > > > stick to Google Docs from your personal Google account,
> > > until
> > > > > > >> > > > it's ready for publication, which would also be fine
> (any
> > > > > > >> > > > interested persons can simply request write access by
> > > replying
> > > > > > >> > > > to the message where
> > > > > > >> you shared the link)..
> > > > > > >> > > >
> > > > > > >> > > > We are a much smaller project than many others, and we
> > have
> > > > > > >> > > > previously suffered from having stuff too spread out.
> Even
> > > if
> > > > > > >> > > > other projects find a separate space valuable for them,
> > I'm
> > > > not
> > > > > > >> > > > sure it's best for the Accumulo project. While I think
> > it's
> > > > > > >> > > > useful to examine what other projects do, I do think we
> > > should
> > > > > > >> > > > be careful to adopt anything just because others find it
> > > > > > convenient for them.
> > > > > > >> > > >
> > > > > > >> > > > Confluence is my second choice, but with a big gap
> between
> > > it
> > > > > > >> > > > and my first choice.
> > > > > > >> > > >
> > > > > > >> > > > On a personal note: I hate using Confluence, because I
> > think
> > > > > > >> > > > the navigation is highly unintuitive, as is the
> > permissions
> > > > > > >> > > > model, and I don't like the idea of learning yet another
> > > > > > >> > > > wiki-syntax (though I've read Confluence supports some
> > > limited
> > > > > > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I
> > > also
> > > > > > >> > > > do not want to set up custom notifications for watching
> > yet
> > > > > > >> > > > another space. If we use Confluence, I will probably
> > > > contribute
> > > > > > >> > > > very infrequently there because of my frustrations with
> > > having
> > > > > > >> > > > used it before. However, that would be my choice, and
> > should
> > > > > > >> > > > not be a reason the project chooses one over another.
> I'm
> > > > > > >> > > > sharing my personal opinion only because it is
> influencing
> > > my
> > > > > > >> > > > opinion about the website being more accessible, via our
> > > > > > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder
> > how
> > > > > > >> > > > many other potential contributors would feel similarly.
> > It's
> > > > > > >> > > > hard to know, since it seems like a lot of this is
> > > subjective,
> > > > > > >> > > > and is going to come down to a consensus of personal
> > > > > > >> preferences.
> > > > > > >> > > >
> > > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > > >> > > > <dm...@gmail.com>
> > > > > > >> > wrote:
> > > > > > >> > > > >
> > > > > > >> > > > > I don't see the website as an area where we would have
> > > > > > >> > > > > collaborative discussions about an idea. For example,
> > > making
> > > > > > >> > > > > comments and
> > > > > > >> > suggestions
> > > > > > >> > > > on
> > > > > > >> > > > > a document like you can do in Google Docs. I see the
> > > website
> > > > > > >> > > > > as a
> > > > > > >> > place
> > > > > > >> > > > > where items are documented for user consumption after
> > > > > > >> > > > > everything has
> > > > > > >> > been
> > > > > > >> > > > > finalized. I'm not trying to create a private
> discussion
> > > > > > >> > > > > area, I
> > > > > > >> > think
> > > > > > >> > > > > anyone can see the wiki (but I think anonymous
> comments
> > > are
> > > > > > >> > > > > disabled
> > > > > > >> > due
> > > > > > >> > > > to
> > > > > > >> > > > > spam issues). I see no issue with putting
> > work-in-progress
> > > > > > >> > > > > documents
> > > > > > >> > on a
> > > > > > >> > > > > wiki and referencing them via emails to the dev list.
> I
> > > > think
> > > > > > >> > > > > this is
> > > > > > >> > > > done
> > > > > > >> > > > > in a lot of other projects. Non-committers that don't
> > have
> > > > > > >> > > > > access to
> > > > > > >> > the
> > > > > > >> > > > > wiki and want to make comments, suggestions, and ask
> > > > > > >> > > > > questions can
> > > > > > >> > do so
> > > > > > >> > > > > via the mailing list. I think it's also possible that
> > > people
> > > > > > >> > > > > can get confluence accounts (see
> > > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > > >> > > > > so if a non-committer wanted to participate they
> could.
> > > > > > >> > > > >
> > > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > > >> > > > > <ct...@apache.org>
> > > > > > >> > wrote:
> > > > > > >> > > > >
> > > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > > >> > > > > > <dm...@gmail.com>
> > > > > > >> > > > wrote:
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > I'm opposed to using the website for the reasons I
> > > > > > >> > > > > > > specified
> > > > > > >> > > > earlier, so
> > > > > > >> > > > > > it
> > > > > > >> > > > > >
> > > > > > >> > > > > > Your reasons that I saw were:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > 1. I don't think internal design discussions
> should
> > go
> > > > on
> > > > > > >> > > > > > > the
> > > > > > >> > project
> > > > > > >> > > > > > website.
> > > > > > >> > > > > >
> > > > > > >> > > > > > That doesn't look to me like a reason. That appears
> to
> > > > just
> > > > > > >> > > > > > be
> > > > > > >> > stating
> > > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > > >> > > > > >
> > > > > > >> > > > > > > 2. Changes to the design documents could not be
> seen
> > > by
> > > > > > >> > > > > > > others
> > > > > > >> > right
> > > > > > >> > > > > > away (IIRC changes to the website are built and
> > > available
> > > > > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > > > > >> > > > > > intervention is
> > > > > > >> > > > required
> > > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > > >> > > > > >
> > > > > > >> > > > > > What do you mean by "others" here? Do you mean
> > "users",
> > > as
> > > > > > >> > > > > > opposed
> > > > > > >> > to
> > > > > > >> > > > > > "developers/contributors"? The ASF draws a
> distinction
> > > > > > >> > > > > > between "developers/contributors" and "users" as it
> > > > > > >> > > > > > pertains to official releases. Releases are intended
> > to
> > > be
> > > > > > >> > > > > > consumed by users, and pre-release stuff is intended
> > to
> > > be
> > > > > > >> > > > > > collaborative, open to all potential
> > > > > > >> > > > > > developers/contributors. Very very rarely are things
> > > > > > >> > > > > > reserved exclusively for committers. We don't even
> > have
> > > a
> > > > > > >> > > > > > private committers space (the private mailing list
> is
> > > > > > >> > > > > > PMC-private, not committer-private). Having a
> > > distinction
> > > > > > >> > > > > > between users and
> > > > > > >> > developers
> > > > > > >> > > > > > doesn't mean we can't publish things on the
> website...
> > > it
> > > > > > >> > > > > > just
> > > > > > >> > means
> > > > > > >> > > > > > that we should be careful about how we do it, which
> is
> > > the
> > > > > > >> > > > > > same
> > > > > > >> > care
> > > > > > >> > > > > > we should take regardless of where we put it.
> > > > Specifically,
> > > > > > >> > > > > > the
> > > > > > >> > care
> > > > > > >> > > > > > we need to take is to avoid marketing pre-release
> > > content
> > > > > > >> > > > > > to
> > > > > > >> users.
> > > > > > >> > > > > > One way we can exercise this care for content on our
> > > > > > >> > > > > > website is
> > > > > > >> > that
> > > > > > >> > > > > > we can avoid sharing these unpolished designs by
> > simply
> > > > not
> > > > > > >> > > > > > linking them on the site, or by placing them in an
> > area
> > > > > > >> > > > > > that is clearly
> > > > > > >> > marked
> > > > > > >> > > > > > as intended for devs. But, we have no similar
> > > distinction
> > > > > > >> > > > > > between committers and non-committer devs for which
> we
> > > > > > >> > > > > > should avoid sharing pre-release content under
> > > > development.
> > > > > > >> > > > > > In fact, it is the
> > > > > > >> > opposite...
> > > > > > >> > > > > > we should be developing openly so as to allow room
> for
> > > > > > >> > non-committers
> > > > > > >> > > > > > to become committers through participation in
> > > development
> > > > > > >> > activities.
> > > > > > >> > > > > >
> > > > > > >> > > > > > As for the staging/publication of the website,
> that's
> > > just
> > > > > > >> > > > > > a
> > > > > > >> > mechanic
> > > > > > >> > > > > > for verifying the website isn't broken before we
> serve
> > > it.
> > > > > > >> > > > > > It's
> > > > > > >> > not a
> > > > > > >> > > > > > mechanism for keeping things internal vs. shared and
> > > > > > >> > > > > > doesn't have anything to do with the separation
> > between
> > > > > > >> > > > > > devs and users. We
> > > > > > >> > already
> > > > > > >> > > > > > publish Draft contents to the website, as well as
> > > > > > >> > developer-specific
> > > > > > >> > > > > > documentation not intended for users.
> > > > > > >> > > > > >
> > > > > > >> > > > > > We've even specifically published work-in-progress
> > > design
> > > > > > >> > > > > > documents there, of the same type that seems to be
> the
> > > > > > >> > > > > > basis of this conversation (
> > > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > > >> > I
> > > > > > >> > > > > > would strongly prefer us to continue to do it this
> > way,
> > > > > > >> > > > > > rather than create a new space, and have these kinds
> > of
> > > > > > >> > > > > > things scattered in multiple places.
> > > > > > >> > > > > >
> > > > > > >> > > > > > If, on the other hand, you intend to say that these
> > > should
> > > > > > >> > > > > > be
> > > > > > >> > private
> > > > > > >> > > > > > because they aren't ready for other potential
> > > > contributors,
> > > > > > >> > > > > > then I would argue that we're an openly developed
> > > > project...
> > > > > > >> > > > > > if something isn't ready to be shared with other
> > > potential
> > > > > > >> > > > > > contributors / developers, such that you want to
> keep
> > it
> > > > > > >> > > > > > internal to existing committers, then it's not ready
> > to
> > > be
> > > > > > >> > > > > > contributed to the project at all... because we
> don't
> > > > > > >> > > > > > restrict collaboration to only existing committers.
> > That
> > > > > > >> > > > > > would prevent others from participating and
> > > > > > >> > earning
> > > > > > >> > > > > > the merit to become committers, and that's not
> > something
> > > > we
> > > > > > >> > > > > > should
> > > > > > >> > be
> > > > > > >> > > > > > doing. Anything that is okay to share with existing
> > > > > > >> > > > > > committers
> > > > > > >> > should
> > > > > > >> > > > > > be okay to share to other potential contributors who
> > > want
> > > > > > >> > > > > > to participate, and should be done in a space that
> > > allows
> > > > > > >> > > > > > them to do that. The website is a perfect space for
> > > that,
> > > > > > >> > > > > > and has everything
> > > > > > >> > we
> > > > > > >> > > > > > need. I'm actually not sure about Confluence... I
> > > suspect
> > > > > > >> > > > > > non-committers wouldn't be able to participate there
> > > > > > >> > > > > > because they probably can't get accounts for it.
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > > looks like we need to
> > > > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious
> how
> > > > much
> > > > > > >> > > > > > > we
> > > > > > >> > need to
> > > > > > >> > > > use
> > > > > > >> > > > > > > the mailing list during
> > > > > > >> > > > > > > the design phase. We can announce meeting
> > dates/times
> > > on
> > > > > > >> > > > > > > the
> > > > > > >> > mailing
> > > > > > >> > > > list
> > > > > > >> > > > > > > and post links to
> > > > > > >> > > > > > > meeting notes in Confluence. Ultimately, decisions
> > > made
> > > > > > >> > > > > > > by the
> > > > > > >> > people
> > > > > > >> > > > > > that
> > > > > > >> > > > > > > want to be involved
> > > > > > >> > > > > > > will turn into pull requests against the codebase
> > > which
> > > > > > >> > comitters can
> > > > > > >> > > > > > weigh
> > > > > > >> > > > > > > in on. When you say,
> > > > > > >> > > > > > > "... but decisions about those would still need to
> > be
> > > > > > >> > > > > > > done on the
> > > > > > >> > > > mailing
> > > > > > >> > > > > > > list." Are you saying that we need to discuss
> every
> > > > > > >> > > > > > > single design decision on the mailing
> > > > > > >> > list?
> > > > > > >> > > > > >
> > > > > > >> > > > > > Yes and no. I am saying that decisions need to
> happen
> > on
> > > > > > >> > > > > > the
> > > > > > >> > mailing
> > > > > > >> > > > > > list, but I agree with you that this can be
> satisfied
> > > > > > >> > > > > > through pull requests. I just wanted to emphasize
> that
> > > > > > >> > > > > > regardless of where we do that pre-decision
> > > collaboration,
> > > > > > >> > > > > > that collaboration should not be misconstrued as a
> > > > decision
> > > > > > >> > > > > > to
> > > > > > >> accept those ideas into the project.
> > > > > > >> > The
> > > > > > >> > > > > > decision occurs during the PR or other activity that
> > > > > > >> > > > > > interfaces
> > > > > > >> > with
> > > > > > >> > > > > > the mailing list, subsequent to the collaboration in
> > the
> > > > > > >> > design/idea
> > > > > > >> > > > > > phase.
> > > > > > >> > > > > >
> > > > > > >> > > > > > As for the pre-decision collaboration space we're
> > > > > > >> > > > > > discussing, I
> > > > > > >> > just
> > > > > > >> > > > > > want to be careful that we're not creating such a
> > space
> > > in
> > > > > > >> > > > > > an exclusionary way that allows only existing
> > committers
> > > > to
> > > > > > >> > participate,
> > > > > > >> > > > > > that excludes other potential contributors. This is
> > > still
> > > > > > >> > > > > > an openly-developed project, and we should
> collaborate
> > > in
> > > > a
> > > > > > >> > > > > > space
> > > > > > >> > that is
> > > > > > >> > > > > > not exclusive to existing committers, but open to
> > > > > > >> > > > > > non-committer contributors and potential
> contributors
> > as
> > > > > well.
> > > > > > >> > > > > > So, while we may
> > > > > > >> > want
> > > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > > >> > > > > > consumption (an important separation that relates to
> > > > > > >> > > > > > official ASF releases), we
> > > > > > >> > should
> > > > > > >> > > > > > not be drawing a line between committer-devs as
> > > "internal"
> > > > > > >> > > > > > and contributor-devs as "external". The website,
> with
> > > its
> > > > > > >> > > > > > own issue tracker, the ability to render markdown,
> do
> > > > > > >> > > > > > reviews, and collaboratively edit, seems like the
> > ideal
> > > > > > >> > > > > > place to me. We've used
> > > > > > >> > it
> > > > > > >> > > > > > before for the same purpose, and I think we should
> > > > continue
> > > > > > >> > > > > > to do
> > > > > > >> > so.
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > > >> > >
> > > > > > >> > > > wrote:
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > > So, I agree a space would be helpful. Although
> > it's
> > > > old
> > > > > > >> > > > > > > > school
> > > > > > >> > and
> > > > > > >> > > > > > > > inconvenient, the mailing list is the canonical
> > > place
> > > > > > >> > > > > > > > for
> > > > > > >> > > > discussion.
> > > > > > >> > > > > > > > We currently use GitHub issues a lot, but that's
> > > > copied
> > > > > > >> > > > > > > > to a
> > > > > > >> > > > mailing
> > > > > > >> > > > > > > > list (as is our old JIRA space), so if people
> want
> > > to
> > > > > > >> > participate
> > > > > > >> > > > > > > > without a GitHub account, they can still do
> that.
> > > > There
> > > > > > >> > > > > > > > are
> > > > > > >> > certain
> > > > > > >> > > > > > > > options that are perhaps less convenient, such
> as
> > > just
> > > > > > >> > > > > > > > using
> > > > > > >> > the
> > > > > > >> > > > > > > > mailing list and our dev SVN space, but still
> more
> > > > > > >> > > > > > > > appropriate
> > > > > > >> > than
> > > > > > >> > > > > > > > options that would be less ubiquitous for
> > potential
> > > > > > >> > participants.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > > > > > >> > > > > > > > storing,
> > > > > > >> > editing,
> > > > > > >> > > > and
> > > > > > >> > > > > > > > collaborating on shared documents, but decisions
> > > about
> > > > > > >> > > > > > > > those
> > > > > > >> > would
> > > > > > >> > > > > > > > still need to be done on the mailing list. If I
> > > > > > >> > > > > > > > remember
> > > > > > >> > > > correctly, we
> > > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > > >> > > > favor
> > > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > > >> > > > > > > > mis-remembering, but
> > > > > > >> > I
> > > > > > >> > > > think
> > > > > > >> > > > > > > > this is the case. It might explain why you can't
> > > > create
> > > > > > >> > > > > > > > a
> > > > > > >> > > > Confluence
> > > > > > >> > > > > > > > space.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > My preference would be to just use the website.
> I
> > > > think
> > > > > > >> > > > > > > > it's
> > > > > > >> > fine
> > > > > > >> > > > to
> > > > > > >> > > > > > > > have a dev / design area of the website, and we
> > can
> > > > > > >> > > > > > > > discuss on
> > > > > > >> > > > GitHub
> > > > > > >> > > > > > > > issues for the accumulo-website repo. That is a
> > bit
> > > > > > >> > > > > > > > less
> > > > > > >> > convenient
> > > > > > >> > > > > > > > than Confluence if it's used heavily, but it's
> > more
> > > > > > >> > > > > > > > convenient
> > > > > > >> > in
> > > > > > >> > > > the
> > > > > > >> > > > > > > > sense that it's more accessible and fits more in
> > > line
> > > > > > >> > > > > > > > with our
> > > > > > >> > > > current
> > > > > > >> > > > > > > > mode of operation. Plus, when a document is
> final,
> > > > it's
> > > > > > >> > > > > > > > easy to
> > > > > > >> > > > link
> > > > > > >> > > > > > > > to from our documentation, without making users
> > jump
> > > > to
> > > > > > >> > > > > > > > another service to view docs.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > I would be opposed to using GitHub wiki or a new
> > git
> > > > > repo.
> > > > > > >> > > > > > > > We
> > > > > > >> > have
> > > > > > >> > > > > > > > enough repos. Although it seems like they are
> > free,
> > > > > > >> > > > > > > > there is
> > > > > > >> > still
> > > > > > >> > > > a
> > > > > > >> > > > > > > > lot of boilerplate work to maintain them, from
> > > > managing
> > > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md,
> etc.,
> > to
> > > > > > >> > .asf.yaml, to
> > > > > > >> > > > > > > > README, to keeping copyright dates updated in
> the
> > > > > > >> > > > > > > > NOTICE file,
> > > > > > >> > and
> > > > > > >> > > > > > > > more.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > In summary, my preference:
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on
> GH
> > > > > > >> > > > > > > > issues and
> > > > > > >> > > > mailing
> > > > > > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss
> > on
> > > > > > >> > > > > > > > mailing list (prefer over other
> > > > > > >> > options,
> > > > > > >> > > > but
> > > > > > >> > > > > > > > not a fan)
> > > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list
> (strongly
> > > > > > >> > > > > > > > prefer not
> > > > > > >> > to use
> > > > > > >> > > > > > this
> > > > > > >> > > > > > > > option)
> > > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> > mailing
> > > > > > >> > > > > > > > list
> > > > > > >> > (strongly
> > > > > > >> > > > > > > > prefer not to use this option)
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > > >> > edcoleman@apache.org>
> > > > > > >> > > > > > wrote:
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > Currently, asf cannot create new wiki's
> because
> > > of a
> > > > > > >> > Confluence
> > > > > > >> > > > > > issue (
> > > > > > >> > > > > > > >
> https://issues.apache.org/jira/browse/INFRA-24291
> > )
> > > I
> > > > > > >> > > > > > > > chatted
> > > > > > >> > with
> > > > > > >> > > > > > infra
> > > > > > >> > > > > > > > and in response they created that issue.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > To expand on this discussion, I would like to
> > toss
> > > > > > >> > > > > > > > > out
> > > > > > >> > another
> > > > > > >> > > > > > > > alternative to discuss / explore. What if we
> > used a
> > > > > > >> > > > > > > > separate
> > > > > > >> > > > GitHub
> > > > > > >> > > > > > > > project, something like Accumulo-Design, just
> > like
> > > > > > >> > accumulo-proxy
> > > > > > >> > > > and
> > > > > > >> > > > > > > > accumulo-examples. As a separate project, it
> > would
> > > be
> > > > > > >> > available
> > > > > > >> > > > for
> > > > > > >> > > > > > > > collaboration for the community, but remain
> > separate
> > > > > > >> > > > > > > > from main
> > > > > > >> > > > project
> > > > > > >> > > > > > and
> > > > > > >> > > > > > > > the website to keep current code /
> documentation /
> > > > > > >> > > > > > > > design
> > > > > > >> > clearly
> > > > > > >> > > > > > separate
> > > > > > >> > > > > > > > from speculative design discussions. As a
> > project:
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > - document history would be preserved with git
> > > > commit
> > > > > > >> > history.
> > > > > > >> > > > > > > > > - document collaboration could be done with
> > normal
> > > > PR
> > > > > > >> > > > submissions /
> > > > > > >> > > > > > > > reviews.
> > > > > > >> > > > > > > > > - issues could be used to discuss design
> > aspects,
> > > > > > >> > > > > > > > > capturing
> > > > > > >> > the
> > > > > > >> > > > > > comment
> > > > > > >> > > > > > > > history.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > The biggest downside is that it would be yet
> > > another
> > > > > > >> > > > > > > > > project
> > > > > > >> > to
> > > > > > >> > > > > > follow /
> > > > > > >> > > > > > > > track.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > For me, I think the issue is that we need a
> > > public,
> > > > > > >> > collaborative
> > > > > > >> > > > > > space
> > > > > > >> > > > > > > > to hold design discussions. Neither the main
> > project
> > > > or
> > > > > > >> > > > > > > > the
> > > > > > >> > > > web-site
> > > > > > >> > > > > > seem
> > > > > > >> > > > > > > > quite appropriate and Confluence seems to lack
> the
> > > > > > >> > collaboration
> > > > > > >> > > > that
> > > > > > >> > > > > > can
> > > > > > >> > > > > > > > be achieved with github.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > We need a space to capture the redesign and
> > > whatever
> > > > > > >> > > > > > > > > we
> > > > > > >> > select
> > > > > > >> > > > can be
> > > > > > >> > > > > > > > made to work - I'm just wondering what provides
> > the
> > > > > > >> > > > > > > > easiest
> > > > > > >> > forum
> > > > > > >> > > > to
> > > > > > >> > > > > > build
> > > > > > >> > > > > > > > a collaborative space for the Accumulo
> community.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > Ed Coleman
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net
> > > wrote:
> > > > > > >> > > > > > > > > > Circling back on this issue - I agree that
> > > > comments
> > > > > > >> > > > > > > > > > and
> > > > > > >> > such
> > > > > > >> > > > make
> > > > > > >> > > > > > > > sense for internal design documents. I'm going
> to
> > > > > > >> > > > > > > > create an
> > > > > > >> > INFRA
> > > > > > >> > > > > > ticket
> > > > > > >> > > > > > > > for a cwiki space for Accumulo unless there are
> > any
> > > > > > >> objections.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > -----Original Message-----
> > > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> > > > > asf.yaml?
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > As mentioned, wikis can provide a
> streamlined
> > > > > > >> > > > > > > > > > collaborative
> > > > > > >> > > > editing
> > > > > > >> > > > > > > > workflow that's less labor intensive than
> > updating a
> > > > > > >> website.
> > > > > > >> > They
> > > > > > >> > > > can
> > > > > > >> > > > > > > > promote collaboration by providing specific
> > tooling
> > > to
> > > > > > >> > > > > > > > support
> > > > > > >> > > > > > comments,
> > > > > > >> > > > > > > > revisions and iteration.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > In terms of preservation, GH wikis act just
> > like
> > > > > > >> > > > > > > > > > any other
> > > > > > >> > Git
> > > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > > git@github.com
> > > > > > :
> > > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > > >> > > > > > > > > > IIRC the pages are just GH flavored
> markdown.
> > > > There
> > > > > > >> > > > > > > > > > are at
> > > > > > >> > > > least a
> > > > > > >> > > > > > few
> > > > > > >> > > > > > > > Apache projects using them.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > However, GH wikis lack some features that I
> > feel
> > > > > > >> > > > > > > > > > are
> > > > > > >> > important
> > > > > > >> > > > to
> > > > > > >> > > > > > > > support collaborative authoring. For example,
> the
> > > > > > >> > > > > > > > ability to
> > > > > > >> > > > comment
> > > > > > >> > > > > > and
> > > > > > >> > > > > > > > discuss specific passages in a document is a
> > feature
> > > > > > >> > > > > > > > that's
> > > > > > >> > > > present in
> > > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate
> > > this
> > > > > > >> > > > > > > > this in
> > > > > > >> > my
> > > > > > >> > > > google
> > > > > > >> > > > > > > > docs and office workflows, so expect that it
> would
> > > be
> > > > > > >> > > > > > > > useful
> > > > > > >> > for
> > > > > > >> > > > > > Accumulo
> > > > > > >> > > > > > > > design discussions too.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith
> Turner <
> > > > > > >> > > > kturner@apache.org>
> > > > > > >> > > > > > > > wrote:
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > > documents,
> > > > > > >> > > > > > > > > > > I think
> > > > > > >> > it
> > > > > > >> > > > > > would be
> > > > > > >> > > > > > > > > > > less cumbersome than the website and we
> can
> > > > > > >> > > > > > > > > > > always link
> > > > > > >> > from
> > > > > > >> > > > the
> > > > > > >> > > > > > > > > > > website and issues to the wiki. I think
> its
> > > ok
> > > > > > >> > > > > > > > > > > to give
> > > > > > >> > it a
> > > > > > >> > > > try
> > > > > > >> > > > > > and
> > > > > > >> > > > > > > > > > > abandon it in the future, if abandoned
> would
> > > > just
> > > > > > >> > > > > > > > > > > need to
> > > > > > >> > > > > > properly
> > > > > > >> > > > > > > > > > > communicate that. The content should be
> > > > archived
> > > > > > >> > > > > > > > > > > in
> > > > > > >> > Apache
> > > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does not do
> > that
> > > > > > >> > > > > > > > > > > then we
> > > > > > >> > should
> > > > > > >> > > > > > not use
> > > > > > >> > > > > > > > > > > it. If GH wiki is not an option then
> could
> > > try
> > > > > > cwiki.
> > > > > > >> > > > > > > > > > >
> > > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > > >> > > > wrote:
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > I reverted the change. I didn't think it
> > > would
> > > > > > >> > > > > > > > > > > > be a big
> > > > > > >> > > > deal,
> > > > > > >> > > > > > but
> > > > > > >> > > > > > > > if
> > > > > > >> > > > > > > > > > > > it
> > > > > > >> > > > > > > > > > > requires discussion, then let's discuss
> it.
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > I'm looking for a place to host
> > information
> > > > > > >> > > > > > > > > > > > related to
> > > > > > >> > > > internal
> > > > > > >> > > > > > > > > > > > design
> > > > > > >> > > > > > > > > > > discussions. I envision these to be living
> > > > > > >> > > > > > > > > > > documents that
> > > > > > >> > > > will be
> > > > > > >> > > > > > > > > > > updated over time as the
> > design/implementation
> > > > > > >> > progresses and
> > > > > > >> > > > > > that
> > > > > > >> > > > > > > > > > > other committers will be able to comment
> on
> > > and
> > > > > > >> > > > > > > > > > > edit. I
> > > > > > >> > don't
> > > > > > >> > > > > > feel
> > > > > > >> > > > > > > > > > > that the website is the correct place for
> > this
> > > > > > >> because:
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > > discussions
> > > > > > >> > > > > > > > > > > > should
> > > > > > >> > go
> > > > > > >> > > > on the
> > > > > > >> > > > > > > > > > > > project
> > > > > > >> > > > > > > > > > > website.
> > > > > > >> > > > > > > > > > > > 2. Changes to the design documents
> could
> > > not
> > > > > > >> > > > > > > > > > > > be seen
> > > > > > >> > by
> > > > > > >> > > > > > others
> > > > > > >> > > > > > > > > > > > right
> > > > > > >> > > > > > > > > > > away (IIRC changes to the website are
> built
> > > and
> > > > > > >> > available at
> > > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but
> > > human
> > > > > > >> > intervention
> > > > > > >> > > > is
> > > > > > >> > > > > > > > > > > required to publish it at
> > > > > > >> https://accumulo.apache.org/).
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > I looked in the INFRA issues and other
> > > > projects
> > > > > > >> > > > > > > > > > > > are
> > > > > > >> > using
> > > > > > >> > > > the
> > > > > > >> > > > > > GH
> > > > > > >> > > > > > > > > > > > Wiki
> > > > > > >> > > > > > > > > > > feature and I saw no mention of backing it
> > up
> > > or
> > > > > > >> > > > > > > > > > > the
> > > > > > >> > > > requirement
> > > > > > >> > > > > > to
> > > > > > >> > > > > > > > do
> > > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing it
> > up?).
> > > > It
> > > > > > >> > > > > > > > > > > does
> > > > > > >> > appear
> > > > > > >> > > > > > that we
> > > > > > >> > > > > > > > > > > would need an INFRA ticket so that they
> can
> > > > > > >> > > > > > > > > > > modify the
> > > > > > >> > GitHub
> > > > > > >> > > > > > project
> > > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down so
> > that
> > > > > > >> > > > > > > > > > > only
> > > > > > >> > > > committers can
> > > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not
> acceptable,
> > > > then
> > > > > > >> > > > > > > > > > > I think
> > > > > > >> > > > Apache
> > > > > > >> > > > > > > > > > > Confluence (
> > > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > > acceptable
> > > > > > >> > > > alternative.
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41
> AM
> > > > > > >> > > > > > > > > > > > To: accumulo-dev <
> dev@accumulo.apache.org
> > >
> > > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> > updated:
> > > > > > >> > > > > > > > > > > > Enable
> > > > > > >> > Github
> > > > > > >> > > > > > wiki in
> > > > > > >> > > > > > > > > > > asf.yaml
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > I don't recall a discussion about this
> > > change,
> > > > > > >> > > > > > > > > > > > but I
> > > > > > >> > think
> > > > > > >> > > > it
> > > > > > >> > > > > > goes
> > > > > > >> > > > > > > > > > > against previous efforts to make the
> website
> > > the
> > > > > > >> > > > > > > > > > > one
> > > > > > >> > > > canonical
> > > > > > >> > > > > > > > > > > location for our documentation. I don't
> even
> > > > > > >> > > > > > > > > > > think infra
> > > > > > >> > is
> > > > > > >> > > > > > backing
> > > > > > >> > > > > > > > up
> > > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a
> > record
> > > > of
> > > > > > >> > > > > > > > > > > the
> > > > > > >> > wiki
> > > > > > >> > > > > > contents
> > > > > > >> > > > > > > > in
> > > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is
> > backed
> > > > up
> > > > > > >> > > > > > > > > > > to
> > > > > > >> > GitBox
> > > > > > >> > > > and
> > > > > > >> > > > > > the
> > > > > > >> > > > > > > > > > > issue tracker, which CCs the notifications
> > > > list).
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > In short, I think this should be
> reverted
> > > and
> > > > > > >> > > > > > > > > > > > we
> > > > > > >> > should not
> > > > > > >> > > > > > use the
> > > > > > >> > > > > > > > > > > GitHub wiki. If we need to store documents
> > in
> > > a
> > > > > > >> > > > > > > > > > > version
> > > > > > >> > > > > > controlled
> > > > > > >> > > > > > > > > > > way, we can store them on the website, or
> in
> > > our
> > > > > > >> > project's
> > > > > > >> > > > SVN
> > > > > > >> > > > > > dev
> > > > > > >> > > > > > > > > > > space. The wiki is just another place
> people
> > > > > > >> > > > > > > > > > > would have
> > > > > > >> > to
> > > > > > >> > > > > > follow if
> > > > > > >> > > > > > > > > > > they want to participate, and I don't
> think
> > > that
> > > > > > >> > > > > > > > > > > serves
> > > > > > >> > us.
> > > > > > >> > > > > > > > Therefore,
> > > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > > >> > wrote:
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > > This is an automated email from the
> ASF
> > > > > > >> > > > > > > > > > > > > dual-hosted
> > > > > > >> > git
> > > > > > >> > > > > > > > repository.
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch
> main
> > in
> > > > > > >> > > > > > > > > > > > > repository
> > > > > > >> > > > > > > > > > > > >
> > > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > > >> > > > > > > > > > > > > git
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > > The following commit(s) were added to
> > > > > > >> > refs/heads/main by
> > > > > > >> > > > this
> > > > > > >> > > > > > > > push:
> > > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki
> > in
> > > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > > >> > > > > > ae8a817e7b is
> > > > > > >> > > > > > > > > > > > > described below
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > > commit
> > > > > > >> > > > > > > > > > > > >
> ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> > dlmarion@apache.org>
> > > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023
> > -0500
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > >> > > > > > > > > > > > > ---
> > > > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml
> index
> > > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > > >> > > > > > > > > > > > > 100644
> > > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > >> > > > > > > > > > > > > - big-data
> > > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > > >> > > > > > > > > > > > > features:
> > > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > > >> > > > > > > > > > > > > issues: true
> > > > > > >> > > > > > > > > > > > > projects: true
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > > >
> > > > > > >> > > > > > > > > > > >
> > > > > > >> > > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
It seems like there's a majority consensus of those engaged. No need for a
vote, but I think the question about notifications should be addressed
first.
On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> I'm +1 to using some kind of wiki so if we can't use Confluence then GH
> sounds fine to me. Do we need to take a formal vote for using the Github
> wiki or is there enough consensus already?
>
> On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com> wrote:
>
> > +1 for the GH wiki with major discussions still being fed into, or
> > originated on the mailing lists.
> >
> > As a side question, if there is a lengthy discussion on a GH issue, is it
> > standard practice to just recap that in a mailing list message?
> > Or is there a more "formal" inclusion process to follow?
> >
> >
> > On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org> wrote:
> >
> > > I don't think the workflow I proposed about using PRs and discussion on
> > > tickets, etc. and the accompanying arguments about keeping things
> > > consolidated and accessible to potential contributors not participating
> > on
> > > GitHub, were really challenged at all. However, since I seem to be the
> > only
> > > one advocating for using the website, to keep things centralized, as
> per
> > > previous attempts to consolidate documentation, I won't fight the use
> of
> > > GitHub wiki. But I do want to make it clear that we're proceeding in
> that
> > > direction under my objection (-0), and that I'm not convinced this is
> the
> > > best path forward. Hopefully, I will be proven wrong in time.
> > >
> > > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> > >
> > > > > At this point, I think we should move forward with a GH wiki and
> then
> > > we
> > > > can re-evaluate things once the Apache confluence issue is sorted
> out.
> > > >
> > > > Agreed.
> > > >
> > > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> > > >
> > > > > I just tried (Wed, 3/15) and still received the same error. I
> asked
> > on
> > > > > the infra slack channel and they replied that they are still
> working
> > to
> > > > > determine what the issue is - signs are pointing to something
> inside
> > of
> > > > > confluence, but no progress.
> > > > >
> > > > > At this point, I think we should move forward with a GH wiki and
> then
> > > we
> > > > > can re-evaluate things once the Apache confluence issue is sorted
> > out.
> > > > >
> > > > > Ed Coleman
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dave Marion <dm...@gmail.com>
> > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > To: dev@accumulo.apache.org
> > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >
> > > > > Looking at the Infra slack channel response, one of the responses
> in
> > > the
> > > > > channel said that "it's some sort of db corruption according to
> > > > Atlassian".
> > > > > Doesn't sound good....
> > > > >
> > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com>
> > > wrote:
> > > > >
> > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > unresolved
> > > > > > and the only comment on the ticket is one that Ed added two days
> > ago
> > > > > > requesting an ACCUMULO wiki space.
> > > > > >
> > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> > > > > >
> > > > > >> I do not see any comments in the infa slack channel - so no
> > updates
> > > > > >> for now.
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Dave Marion <dm...@gmail.com>
> > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > >> To: dev@accumulo.apache.org
> > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > >>
> > > > > >> Right, I was just curious if there was any follow-up as I think
> Ed
> > > > > >> said that it was going to be discussed by the INFRA team
> > yesterday.
> > > > > >> There is at least one other recent ticket (
> > > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> > selfserve
> > > > > >> had an issue and the INFRA team created the space manually.
> > > > > >>
> > > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <
> ctubbsii@apache.org>
> > > > > wrote:
> > > > > >>
> > > > > >> > You can track that issue at
> > > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > > >> >
> > > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> > dmarion18@gmail.com>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > Ed,
> > > > > >> > >
> > > > > >> > > Any update from INFRA on being able to create confluence
> > > pages?
> > > > > >> > >
> > > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> > ctubbsii@apache.org
> > > >
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > > We've definitely used the website for more than that. We
> use
> > > it
> > > > > >> > > > to document things for users, help developers know how to
> > > > > >> > > > contribute, store drafts of designs, share user stories
> via
> > > > > >> > > > blogs, do release announcements, and more. There's
> > definitely
> > > > > >> > > > space on the website to do this kind of thing, if we want
> > to.
> > > > > >> > > > We've used it that way before. If you only see it as a
> place
> > > > > >> > > > "for user consumption after everything has been
> finalized",
> > > > > >> > > > then you're missing out on the other ways we currently use
> > the
> > > > > >> > > > site, and the ways we've used it in
> > > > > >> the past.
> > > > > >> > > >
> > > > > >> > > > With the website, most of the collaboration would happen
> in
> > > the
> > > > > >> > > > GH issues about proposed designs or changes to designs,
> just
> > > > > >> > > > like we do today with code or other documentation, which
> > > > > >> > > > everybody is used to. I agree it's not as good as Google
> > Docs
> > > > > >> > > > for on-the-fly comments/annotations, but I don't think
> > > > > >> > > > Confluence or Wiki are as good as that either, and Google
> > Docs
> > > > > isn't really an option...
> > > > > >> > > > unless you just want to link to it in the mailing list and
> > > > > >> > > > stick to Google Docs from your personal Google account,
> > until
> > > > > >> > > > it's ready for publication, which would also be fine (any
> > > > > >> > > > interested persons can simply request write access by
> > replying
> > > > > >> > > > to the message where
> > > > > >> you shared the link)..
> > > > > >> > > >
> > > > > >> > > > We are a much smaller project than many others, and we
> have
> > > > > >> > > > previously suffered from having stuff too spread out. Even
> > if
> > > > > >> > > > other projects find a separate space valuable for them,
> I'm
> > > not
> > > > > >> > > > sure it's best for the Accumulo project. While I think
> it's
> > > > > >> > > > useful to examine what other projects do, I do think we
> > should
> > > > > >> > > > be careful to adopt anything just because others find it
> > > > > convenient for them.
> > > > > >> > > >
> > > > > >> > > > Confluence is my second choice, but with a big gap between
> > it
> > > > > >> > > > and my first choice.
> > > > > >> > > >
> > > > > >> > > > On a personal note: I hate using Confluence, because I
> think
> > > > > >> > > > the navigation is highly unintuitive, as is the
> permissions
> > > > > >> > > > model, and I don't like the idea of learning yet another
> > > > > >> > > > wiki-syntax (though I've read Confluence supports some
> > limited
> > > > > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I
> > also
> > > > > >> > > > do not want to set up custom notifications for watching
> yet
> > > > > >> > > > another space. If we use Confluence, I will probably
> > > contribute
> > > > > >> > > > very infrequently there because of my frustrations with
> > having
> > > > > >> > > > used it before. However, that would be my choice, and
> should
> > > > > >> > > > not be a reason the project chooses one over another. I'm
> > > > > >> > > > sharing my personal opinion only because it is influencing
> > my
> > > > > >> > > > opinion about the website being more accessible, via our
> > > > > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder
> how
> > > > > >> > > > many other potential contributors would feel similarly.
> It's
> > > > > >> > > > hard to know, since it seems like a lot of this is
> > subjective,
> > > > > >> > > > and is going to come down to a consensus of personal
> > > > > >> preferences.
> > > > > >> > > >
> > > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > > >> > > > <dm...@gmail.com>
> > > > > >> > wrote:
> > > > > >> > > > >
> > > > > >> > > > > I don't see the website as an area where we would have
> > > > > >> > > > > collaborative discussions about an idea. For example,
> > making
> > > > > >> > > > > comments and
> > > > > >> > suggestions
> > > > > >> > > > on
> > > > > >> > > > > a document like you can do in Google Docs. I see the
> > website
> > > > > >> > > > > as a
> > > > > >> > place
> > > > > >> > > > > where items are documented for user consumption after
> > > > > >> > > > > everything has
> > > > > >> > been
> > > > > >> > > > > finalized. I'm not trying to create a private discussion
> > > > > >> > > > > area, I
> > > > > >> > think
> > > > > >> > > > > anyone can see the wiki (but I think anonymous comments
> > are
> > > > > >> > > > > disabled
> > > > > >> > due
> > > > > >> > > > to
> > > > > >> > > > > spam issues). I see no issue with putting
> work-in-progress
> > > > > >> > > > > documents
> > > > > >> > on a
> > > > > >> > > > > wiki and referencing them via emails to the dev list. I
> > > think
> > > > > >> > > > > this is
> > > > > >> > > > done
> > > > > >> > > > > in a lot of other projects. Non-committers that don't
> have
> > > > > >> > > > > access to
> > > > > >> > the
> > > > > >> > > > > wiki and want to make comments, suggestions, and ask
> > > > > >> > > > > questions can
> > > > > >> > do so
> > > > > >> > > > > via the mailing list. I think it's also possible that
> > people
> > > > > >> > > > > can get confluence accounts (see
> > > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > >> > > > > so if a non-committer wanted to participate they could.
> > > > > >> > > > >
> > > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > > >> > > > > <ct...@apache.org>
> > > > > >> > wrote:
> > > > > >> > > > >
> > > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > >> > > > > > <dm...@gmail.com>
> > > > > >> > > > wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > > I'm opposed to using the website for the reasons I
> > > > > >> > > > > > > specified
> > > > > >> > > > earlier, so
> > > > > >> > > > > > it
> > > > > >> > > > > >
> > > > > >> > > > > > Your reasons that I saw were:
> > > > > >> > > > > >
> > > > > >> > > > > > > 1. I don't think internal design discussions should
> go
> > > on
> > > > > >> > > > > > > the
> > > > > >> > project
> > > > > >> > > > > > website.
> > > > > >> > > > > >
> > > > > >> > > > > > That doesn't look to me like a reason. That appears to
> > > just
> > > > > >> > > > > > be
> > > > > >> > stating
> > > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > > >> > > > > >
> > > > > >> > > > > > > 2. Changes to the design documents could not be seen
> > by
> > > > > >> > > > > > > others
> > > > > >> > right
> > > > > >> > > > > > away (IIRC changes to the website are built and
> > available
> > > > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > > > >> > > > > > intervention is
> > > > > >> > > > required
> > > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > >> > > > > >
> > > > > >> > > > > > What do you mean by "others" here? Do you mean
> "users",
> > as
> > > > > >> > > > > > opposed
> > > > > >> > to
> > > > > >> > > > > > "developers/contributors"? The ASF draws a distinction
> > > > > >> > > > > > between "developers/contributors" and "users" as it
> > > > > >> > > > > > pertains to official releases. Releases are intended
> to
> > be
> > > > > >> > > > > > consumed by users, and pre-release stuff is intended
> to
> > be
> > > > > >> > > > > > collaborative, open to all potential
> > > > > >> > > > > > developers/contributors. Very very rarely are things
> > > > > >> > > > > > reserved exclusively for committers. We don't even
> have
> > a
> > > > > >> > > > > > private committers space (the private mailing list is
> > > > > >> > > > > > PMC-private, not committer-private). Having a
> > distinction
> > > > > >> > > > > > between users and
> > > > > >> > developers
> > > > > >> > > > > > doesn't mean we can't publish things on the website...
> > it
> > > > > >> > > > > > just
> > > > > >> > means
> > > > > >> > > > > > that we should be careful about how we do it, which is
> > the
> > > > > >> > > > > > same
> > > > > >> > care
> > > > > >> > > > > > we should take regardless of where we put it.
> > > Specifically,
> > > > > >> > > > > > the
> > > > > >> > care
> > > > > >> > > > > > we need to take is to avoid marketing pre-release
> > content
> > > > > >> > > > > > to
> > > > > >> users.
> > > > > >> > > > > > One way we can exercise this care for content on our
> > > > > >> > > > > > website is
> > > > > >> > that
> > > > > >> > > > > > we can avoid sharing these unpolished designs by
> simply
> > > not
> > > > > >> > > > > > linking them on the site, or by placing them in an
> area
> > > > > >> > > > > > that is clearly
> > > > > >> > marked
> > > > > >> > > > > > as intended for devs. But, we have no similar
> > distinction
> > > > > >> > > > > > between committers and non-committer devs for which we
> > > > > >> > > > > > should avoid sharing pre-release content under
> > > development.
> > > > > >> > > > > > In fact, it is the
> > > > > >> > opposite...
> > > > > >> > > > > > we should be developing openly so as to allow room for
> > > > > >> > non-committers
> > > > > >> > > > > > to become committers through participation in
> > development
> > > > > >> > activities.
> > > > > >> > > > > >
> > > > > >> > > > > > As for the staging/publication of the website, that's
> > just
> > > > > >> > > > > > a
> > > > > >> > mechanic
> > > > > >> > > > > > for verifying the website isn't broken before we serve
> > it.
> > > > > >> > > > > > It's
> > > > > >> > not a
> > > > > >> > > > > > mechanism for keeping things internal vs. shared and
> > > > > >> > > > > > doesn't have anything to do with the separation
> between
> > > > > >> > > > > > devs and users. We
> > > > > >> > already
> > > > > >> > > > > > publish Draft contents to the website, as well as
> > > > > >> > developer-specific
> > > > > >> > > > > > documentation not intended for users.
> > > > > >> > > > > >
> > > > > >> > > > > > We've even specifically published work-in-progress
> > design
> > > > > >> > > > > > documents there, of the same type that seems to be the
> > > > > >> > > > > > basis of this conversation (
> > > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > > >> > I
> > > > > >> > > > > > would strongly prefer us to continue to do it this
> way,
> > > > > >> > > > > > rather than create a new space, and have these kinds
> of
> > > > > >> > > > > > things scattered in multiple places.
> > > > > >> > > > > >
> > > > > >> > > > > > If, on the other hand, you intend to say that these
> > should
> > > > > >> > > > > > be
> > > > > >> > private
> > > > > >> > > > > > because they aren't ready for other potential
> > > contributors,
> > > > > >> > > > > > then I would argue that we're an openly developed
> > > project...
> > > > > >> > > > > > if something isn't ready to be shared with other
> > potential
> > > > > >> > > > > > contributors / developers, such that you want to keep
> it
> > > > > >> > > > > > internal to existing committers, then it's not ready
> to
> > be
> > > > > >> > > > > > contributed to the project at all... because we don't
> > > > > >> > > > > > restrict collaboration to only existing committers.
> That
> > > > > >> > > > > > would prevent others from participating and
> > > > > >> > earning
> > > > > >> > > > > > the merit to become committers, and that's not
> something
> > > we
> > > > > >> > > > > > should
> > > > > >> > be
> > > > > >> > > > > > doing. Anything that is okay to share with existing
> > > > > >> > > > > > committers
> > > > > >> > should
> > > > > >> > > > > > be okay to share to other potential contributors who
> > want
> > > > > >> > > > > > to participate, and should be done in a space that
> > allows
> > > > > >> > > > > > them to do that. The website is a perfect space for
> > that,
> > > > > >> > > > > > and has everything
> > > > > >> > we
> > > > > >> > > > > > need. I'm actually not sure about Confluence... I
> > suspect
> > > > > >> > > > > > non-committers wouldn't be able to participate there
> > > > > >> > > > > > because they probably can't get accounts for it.
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > > looks like we need to
> > > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious how
> > > much
> > > > > >> > > > > > > we
> > > > > >> > need to
> > > > > >> > > > use
> > > > > >> > > > > > > the mailing list during
> > > > > >> > > > > > > the design phase. We can announce meeting
> dates/times
> > on
> > > > > >> > > > > > > the
> > > > > >> > mailing
> > > > > >> > > > list
> > > > > >> > > > > > > and post links to
> > > > > >> > > > > > > meeting notes in Confluence. Ultimately, decisions
> > made
> > > > > >> > > > > > > by the
> > > > > >> > people
> > > > > >> > > > > > that
> > > > > >> > > > > > > want to be involved
> > > > > >> > > > > > > will turn into pull requests against the codebase
> > which
> > > > > >> > comitters can
> > > > > >> > > > > > weigh
> > > > > >> > > > > > > in on. When you say,
> > > > > >> > > > > > > "... but decisions about those would still need to
> be
> > > > > >> > > > > > > done on the
> > > > > >> > > > mailing
> > > > > >> > > > > > > list." Are you saying that we need to discuss every
> > > > > >> > > > > > > single design decision on the mailing
> > > > > >> > list?
> > > > > >> > > > > >
> > > > > >> > > > > > Yes and no. I am saying that decisions need to happen
> on
> > > > > >> > > > > > the
> > > > > >> > mailing
> > > > > >> > > > > > list, but I agree with you that this can be satisfied
> > > > > >> > > > > > through pull requests. I just wanted to emphasize that
> > > > > >> > > > > > regardless of where we do that pre-decision
> > collaboration,
> > > > > >> > > > > > that collaboration should not be misconstrued as a
> > > decision
> > > > > >> > > > > > to
> > > > > >> accept those ideas into the project.
> > > > > >> > The
> > > > > >> > > > > > decision occurs during the PR or other activity that
> > > > > >> > > > > > interfaces
> > > > > >> > with
> > > > > >> > > > > > the mailing list, subsequent to the collaboration in
> the
> > > > > >> > design/idea
> > > > > >> > > > > > phase.
> > > > > >> > > > > >
> > > > > >> > > > > > As for the pre-decision collaboration space we're
> > > > > >> > > > > > discussing, I
> > > > > >> > just
> > > > > >> > > > > > want to be careful that we're not creating such a
> space
> > in
> > > > > >> > > > > > an exclusionary way that allows only existing
> committers
> > > to
> > > > > >> > participate,
> > > > > >> > > > > > that excludes other potential contributors. This is
> > still
> > > > > >> > > > > > an openly-developed project, and we should collaborate
> > in
> > > a
> > > > > >> > > > > > space
> > > > > >> > that is
> > > > > >> > > > > > not exclusive to existing committers, but open to
> > > > > >> > > > > > non-committer contributors and potential contributors
> as
> > > > well.
> > > > > >> > > > > > So, while we may
> > > > > >> > want
> > > > > >> > > > > > to keep a line separating dev activity from user
> > > > > >> > > > > > consumption (an important separation that relates to
> > > > > >> > > > > > official ASF releases), we
> > > > > >> > should
> > > > > >> > > > > > not be drawing a line between committer-devs as
> > "internal"
> > > > > >> > > > > > and contributor-devs as "external". The website, with
> > its
> > > > > >> > > > > > own issue tracker, the ability to render markdown, do
> > > > > >> > > > > > reviews, and collaboratively edit, seems like the
> ideal
> > > > > >> > > > > > place to me. We've used
> > > > > >> > it
> > > > > >> > > > > > before for the same purpose, and I think we should
> > > continue
> > > > > >> > > > > > to do
> > > > > >> > so.
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > >> > > > > > > <ctubbsii@apache.org
> > > > > >> > >
> > > > > >> > > > wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > > > So, I agree a space would be helpful. Although
> it's
> > > old
> > > > > >> > > > > > > > school
> > > > > >> > and
> > > > > >> > > > > > > > inconvenient, the mailing list is the canonical
> > place
> > > > > >> > > > > > > > for
> > > > > >> > > > discussion.
> > > > > >> > > > > > > > We currently use GitHub issues a lot, but that's
> > > copied
> > > > > >> > > > > > > > to a
> > > > > >> > > > mailing
> > > > > >> > > > > > > > list (as is our old JIRA space), so if people want
> > to
> > > > > >> > participate
> > > > > >> > > > > > > > without a GitHub account, they can still do that.
> > > There
> > > > > >> > > > > > > > are
> > > > > >> > certain
> > > > > >> > > > > > > > options that are perhaps less convenient, such as
> > just
> > > > > >> > > > > > > > using
> > > > > >> > the
> > > > > >> > > > > > > > mailing list and our dev SVN space, but still more
> > > > > >> > > > > > > > appropriate
> > > > > >> > than
> > > > > >> > > > > > > > options that would be less ubiquitous for
> potential
> > > > > >> > participants.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > > > > >> > > > > > > > storing,
> > > > > >> > editing,
> > > > > >> > > > and
> > > > > >> > > > > > > > collaborating on shared documents, but decisions
> > about
> > > > > >> > > > > > > > those
> > > > > >> > would
> > > > > >> > > > > > > > still need to be done on the mailing list. If I
> > > > > >> > > > > > > > remember
> > > > > >> > > > correctly, we
> > > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > > >> > > > > > > > maintained, so we abandoned it in
> > > > > >> > > > favor
> > > > > >> > > > > > > > of using the website for docs. I could be
> > > > > >> > > > > > > > mis-remembering, but
> > > > > >> > I
> > > > > >> > > > think
> > > > > >> > > > > > > > this is the case. It might explain why you can't
> > > create
> > > > > >> > > > > > > > a
> > > > > >> > > > Confluence
> > > > > >> > > > > > > > space.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > My preference would be to just use the website. I
> > > think
> > > > > >> > > > > > > > it's
> > > > > >> > fine
> > > > > >> > > > to
> > > > > >> > > > > > > > have a dev / design area of the website, and we
> can
> > > > > >> > > > > > > > discuss on
> > > > > >> > > > GitHub
> > > > > >> > > > > > > > issues for the accumulo-website repo. That is a
> bit
> > > > > >> > > > > > > > less
> > > > > >> > convenient
> > > > > >> > > > > > > > than Confluence if it's used heavily, but it's
> more
> > > > > >> > > > > > > > convenient
> > > > > >> > in
> > > > > >> > > > the
> > > > > >> > > > > > > > sense that it's more accessible and fits more in
> > line
> > > > > >> > > > > > > > with our
> > > > > >> > > > current
> > > > > >> > > > > > > > mode of operation. Plus, when a document is final,
> > > it's
> > > > > >> > > > > > > > easy to
> > > > > >> > > > link
> > > > > >> > > > > > > > to from our documentation, without making users
> jump
> > > to
> > > > > >> > > > > > > > another service to view docs.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I would be opposed to using GitHub wiki or a new
> git
> > > > repo.
> > > > > >> > > > > > > > We
> > > > > >> > have
> > > > > >> > > > > > > > enough repos. Although it seems like they are
> free,
> > > > > >> > > > > > > > there is
> > > > > >> > still
> > > > > >> > > > a
> > > > > >> > > > > > > > lot of boilerplate work to maintain them, from
> > > managing
> > > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc.,
> to
> > > > > >> > .asf.yaml, to
> > > > > >> > > > > > > > README, to keeping copyright dates updated in the
> > > > > >> > > > > > > > NOTICE file,
> > > > > >> > and
> > > > > >> > > > > > > > more.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > In summary, my preference:
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
> > > > > >> > > > > > > > issues and
> > > > > >> > > > mailing
> > > > > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss
> on
> > > > > >> > > > > > > > mailing list (prefer over other
> > > > > >> > options,
> > > > > >> > > > but
> > > > > >> > > > > > > > not a fan)
> > > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
> > > > > >> > > > > > > > prefer not
> > > > > >> > to use
> > > > > >> > > > > > this
> > > > > >> > > > > > > > option)
> > > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and
> mailing
> > > > > >> > > > > > > > list
> > > > > >> > (strongly
> > > > > >> > > > > > > > prefer not to use this option)
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > > >> > edcoleman@apache.org>
> > > > > >> > > > > > wrote:
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > Currently, asf cannot create new wiki's because
> > of a
> > > > > >> > Confluence
> > > > > >> > > > > > issue (
> > > > > >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291
> )
> > I
> > > > > >> > > > > > > > chatted
> > > > > >> > with
> > > > > >> > > > > > infra
> > > > > >> > > > > > > > and in response they created that issue.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > To expand on this discussion, I would like to
> toss
> > > > > >> > > > > > > > > out
> > > > > >> > another
> > > > > >> > > > > > > > alternative to discuss / explore. What if we
> used a
> > > > > >> > > > > > > > separate
> > > > > >> > > > GitHub
> > > > > >> > > > > > > > project, something like Accumulo-Design, just
> like
> > > > > >> > accumulo-proxy
> > > > > >> > > > and
> > > > > >> > > > > > > > accumulo-examples. As a separate project, it
> would
> > be
> > > > > >> > available
> > > > > >> > > > for
> > > > > >> > > > > > > > collaboration for the community, but remain
> separate
> > > > > >> > > > > > > > from main
> > > > > >> > > > project
> > > > > >> > > > > > and
> > > > > >> > > > > > > > the website to keep current code / documentation /
> > > > > >> > > > > > > > design
> > > > > >> > clearly
> > > > > >> > > > > > separate
> > > > > >> > > > > > > > from speculative design discussions. As a
> project:
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > - document history would be preserved with git
> > > commit
> > > > > >> > history.
> > > > > >> > > > > > > > > - document collaboration could be done with
> normal
> > > PR
> > > > > >> > > > submissions /
> > > > > >> > > > > > > > reviews.
> > > > > >> > > > > > > > > - issues could be used to discuss design
> aspects,
> > > > > >> > > > > > > > > capturing
> > > > > >> > the
> > > > > >> > > > > > comment
> > > > > >> > > > > > > > history.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > The biggest downside is that it would be yet
> > another
> > > > > >> > > > > > > > > project
> > > > > >> > to
> > > > > >> > > > > > follow /
> > > > > >> > > > > > > > track.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > For me, I think the issue is that we need a
> > public,
> > > > > >> > collaborative
> > > > > >> > > > > > space
> > > > > >> > > > > > > > to hold design discussions. Neither the main
> project
> > > or
> > > > > >> > > > > > > > the
> > > > > >> > > > web-site
> > > > > >> > > > > > seem
> > > > > >> > > > > > > > quite appropriate and Confluence seems to lack the
> > > > > >> > collaboration
> > > > > >> > > > that
> > > > > >> > > > > > can
> > > > > >> > > > > > > > be achieved with github.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > We need a space to capture the redesign and
> > whatever
> > > > > >> > > > > > > > > we
> > > > > >> > select
> > > > > >> > > > can be
> > > > > >> > > > > > > > made to work - I'm just wondering what provides
> the
> > > > > >> > > > > > > > easiest
> > > > > >> > forum
> > > > > >> > > > to
> > > > > >> > > > > > build
> > > > > >> > > > > > > > a collaborative space for the Accumulo community.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > Ed Coleman
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net
> > wrote:
> > > > > >> > > > > > > > > > Circling back on this issue - I agree that
> > > comments
> > > > > >> > > > > > > > > > and
> > > > > >> > such
> > > > > >> > > > make
> > > > > >> > > > > > > > sense for internal design documents. I'm going to
> > > > > >> > > > > > > > create an
> > > > > >> > INFRA
> > > > > >> > > > > > ticket
> > > > > >> > > > > > > > for a cwiki space for Accumulo unless there are
> any
> > > > > >> objections.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > -----Original Message-----
> > > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> > > > asf.yaml?
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > As mentioned, wikis can provide a streamlined
> > > > > >> > > > > > > > > > collaborative
> > > > > >> > > > editing
> > > > > >> > > > > > > > workflow that's less labor intensive than
> updating a
> > > > > >> website.
> > > > > >> > They
> > > > > >> > > > can
> > > > > >> > > > > > > > promote collaboration by providing specific
> tooling
> > to
> > > > > >> > > > > > > > support
> > > > > >> > > > > > comments,
> > > > > >> > > > > > > > revisions and iteration.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > In terms of preservation, GH wikis act just
> like
> > > > > >> > > > > > > > > > any other
> > > > > >> > Git
> > > > > >> > > > > > > > repository, with a remote at (for example)
> > > > git@github.com
> > > > > :
> > > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > > >> > > > > > > > > > IIRC the pages are just GH flavored markdown.
> > > There
> > > > > >> > > > > > > > > > are at
> > > > > >> > > > least a
> > > > > >> > > > > > few
> > > > > >> > > > > > > > Apache projects using them.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > However, GH wikis lack some features that I
> feel
> > > > > >> > > > > > > > > > are
> > > > > >> > important
> > > > > >> > > > to
> > > > > >> > > > > > > > support collaborative authoring. For example, the
> > > > > >> > > > > > > > ability to
> > > > > >> > > > comment
> > > > > >> > > > > > and
> > > > > >> > > > > > > > discuss specific passages in a document is a
> feature
> > > > > >> > > > > > > > that's
> > > > > >> > > > present in
> > > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate
> > this
> > > > > >> > > > > > > > this in
> > > > > >> > my
> > > > > >> > > > google
> > > > > >> > > > > > > > docs and office workflows, so expect that it would
> > be
> > > > > >> > > > > > > > useful
> > > > > >> > for
> > > > > >> > > > > > Accumulo
> > > > > >> > > > > > > > design discussions too.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > > > >> > > > kturner@apache.org>
> > > > > >> > > > > > > > wrote:
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > > I would like to try a wiki for design
> > documents,
> > > > > >> > > > > > > > > > > I think
> > > > > >> > it
> > > > > >> > > > > > would be
> > > > > >> > > > > > > > > > > less cumbersome than the website and we can
> > > > > >> > > > > > > > > > > always link
> > > > > >> > from
> > > > > >> > > > the
> > > > > >> > > > > > > > > > > website and issues to the wiki. I think its
> > ok
> > > > > >> > > > > > > > > > > to give
> > > > > >> > it a
> > > > > >> > > > try
> > > > > >> > > > > > and
> > > > > >> > > > > > > > > > > abandon it in the future, if abandoned would
> > > just
> > > > > >> > > > > > > > > > > need to
> > > > > >> > > > > > properly
> > > > > >> > > > > > > > > > > communicate that. The content should be
> > > archived
> > > > > >> > > > > > > > > > > in
> > > > > >> > Apache
> > > > > >> > > > > > > > > > > infrastructure, so if GH wiki does not do
> that
> > > > > >> > > > > > > > > > > then we
> > > > > >> > should
> > > > > >> > > > > > not use
> > > > > >> > > > > > > > > > > it. If GH wiki is not an option then could
> > try
> > > > > cwiki.
> > > > > >> > > > > > > > > > >
> > > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > > >> > > > wrote:
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I reverted the change. I didn't think it
> > would
> > > > > >> > > > > > > > > > > > be a big
> > > > > >> > > > deal,
> > > > > >> > > > > > but
> > > > > >> > > > > > > > if
> > > > > >> > > > > > > > > > > > it
> > > > > >> > > > > > > > > > > requires discussion, then let's discuss it.
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I'm looking for a place to host
> information
> > > > > >> > > > > > > > > > > > related to
> > > > > >> > > > internal
> > > > > >> > > > > > > > > > > > design
> > > > > >> > > > > > > > > > > discussions. I envision these to be living
> > > > > >> > > > > > > > > > > documents that
> > > > > >> > > > will be
> > > > > >> > > > > > > > > > > updated over time as the
> design/implementation
> > > > > >> > progresses and
> > > > > >> > > > > > that
> > > > > >> > > > > > > > > > > other committers will be able to comment on
> > and
> > > > > >> > > > > > > > > > > edit. I
> > > > > >> > don't
> > > > > >> > > > > > feel
> > > > > >> > > > > > > > > > > that the website is the correct place for
> this
> > > > > >> because:
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > 1. I don't think internal design
> > discussions
> > > > > >> > > > > > > > > > > > should
> > > > > >> > go
> > > > > >> > > > on the
> > > > > >> > > > > > > > > > > > project
> > > > > >> > > > > > > > > > > website.
> > > > > >> > > > > > > > > > > > 2. Changes to the design documents could
> > not
> > > > > >> > > > > > > > > > > > be seen
> > > > > >> > by
> > > > > >> > > > > > others
> > > > > >> > > > > > > > > > > > right
> > > > > >> > > > > > > > > > > away (IIRC changes to the website are built
> > and
> > > > > >> > available at
> > > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but
> > human
> > > > > >> > intervention
> > > > > >> > > > is
> > > > > >> > > > > > > > > > > required to publish it at
> > > > > >> https://accumulo.apache.org/).
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I looked in the INFRA issues and other
> > > projects
> > > > > >> > > > > > > > > > > > are
> > > > > >> > using
> > > > > >> > > > the
> > > > > >> > > > > > GH
> > > > > >> > > > > > > > > > > > Wiki
> > > > > >> > > > > > > > > > > feature and I saw no mention of backing it
> up
> > or
> > > > > >> > > > > > > > > > > the
> > > > > >> > > > requirement
> > > > > >> > > > > > to
> > > > > >> > > > > > > > do
> > > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing it
> up?).
> > > It
> > > > > >> > > > > > > > > > > does
> > > > > >> > appear
> > > > > >> > > > > > that we
> > > > > >> > > > > > > > > > > would need an INFRA ticket so that they can
> > > > > >> > > > > > > > > > > modify the
> > > > > >> > GitHub
> > > > > >> > > > > > project
> > > > > >> > > > > > > > > > > settings to lock the GitHub wiki down so
> that
> > > > > >> > > > > > > > > > > only
> > > > > >> > > > committers can
> > > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable,
> > > then
> > > > > >> > > > > > > > > > > I think
> > > > > >> > > > Apache
> > > > > >> > > > > > > > > > > Confluence (
> > > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > > acceptable
> > > > > >> > > > alternative.
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > -----Original Message-----
> > > > > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > >> > > > > > > > > > > > To: accumulo-dev <dev@accumulo.apache.org
> >
> > > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main
> updated:
> > > > > >> > > > > > > > > > > > Enable
> > > > > >> > Github
> > > > > >> > > > > > wiki in
> > > > > >> > > > > > > > > > > asf.yaml
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > I don't recall a discussion about this
> > change,
> > > > > >> > > > > > > > > > > > but I
> > > > > >> > think
> > > > > >> > > > it
> > > > > >> > > > > > goes
> > > > > >> > > > > > > > > > > against previous efforts to make the website
> > the
> > > > > >> > > > > > > > > > > one
> > > > > >> > > > canonical
> > > > > >> > > > > > > > > > > location for our documentation. I don't even
> > > > > >> > > > > > > > > > > think infra
> > > > > >> > is
> > > > > >> > > > > > backing
> > > > > >> > > > > > > > up
> > > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a
> record
> > > of
> > > > > >> > > > > > > > > > > the
> > > > > >> > wiki
> > > > > >> > > > > > contents
> > > > > >> > > > > > > > in
> > > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is
> backed
> > > up
> > > > > >> > > > > > > > > > > to
> > > > > >> > GitBox
> > > > > >> > > > and
> > > > > >> > > > > > the
> > > > > >> > > > > > > > > > > issue tracker, which CCs the notifications
> > > list).
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > In short, I think this should be reverted
> > and
> > > > > >> > > > > > > > > > > > we
> > > > > >> > should not
> > > > > >> > > > > > use the
> > > > > >> > > > > > > > > > > GitHub wiki. If we need to store documents
> in
> > a
> > > > > >> > > > > > > > > > > version
> > > > > >> > > > > > controlled
> > > > > >> > > > > > > > > > > way, we can store them on the website, or in
> > our
> > > > > >> > project's
> > > > > >> > > > SVN
> > > > > >> > > > > > dev
> > > > > >> > > > > > > > > > > space. The wiki is just another place people
> > > > > >> > > > > > > > > > > would have
> > > > > >> > to
> > > > > >> > > > > > follow if
> > > > > >> > > > > > > > > > > they want to participate, and I don't think
> > that
> > > > > >> > > > > > > > > > > serves
> > > > > >> > us.
> > > > > >> > > > > > > > Therefore,
> > > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > > >> > wrote:
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > This is an automated email from the ASF
> > > > > >> > > > > > > > > > > > > dual-hosted
> > > > > >> > git
> > > > > >> > > > > > > > repository.
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch main
> in
> > > > > >> > > > > > > > > > > > > repository
> > > > > >> > > > > > > > > > > > >
> > > https://gitbox.apache.org/repos/asf/accumulo.
> > > > > >> > > > > > > > > > > > > git
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > The following commit(s) were added to
> > > > > >> > refs/heads/main by
> > > > > >> > > > this
> > > > > >> > > > > > > > push:
> > > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki
> in
> > > > > >> > > > > > > > > > > > > asf.yaml
> > > > > >> > > > > > ae8a817e7b is
> > > > > >> > > > > > > > > > > > > described below
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > commit
> > > > > >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > >> > > > > > > > > > > > > Author: Dave Marion <
> dlmarion@apache.org>
> > > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023
> -0500
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > >> > > > > > > > > > > > > ---
> > > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > > >> > > > > > > > > > > > > deletion(-)
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > > >> > > > > > bc2c943e82..08aa357082
> > > > > >> > > > > > > > > > > > > 100644
> > > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > >> > > > > > > > > > > > > - big-data
> > > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > > >> > > > > > > > > > > > > features:
> > > > > >> > > > > > > > > > > > > - wiki: false
> > > > > >> > > > > > > > > > > > > + wiki: true
> > > > > >> > > > > > > > > > > > > issues: true
> > > > > >> > > > > > > > > > > > > projects: true
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > > >
> > > > > >> > > > > > > > > > > >
> > > > > >> > > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > >
> > > > > >> > > > > >
> > > > > >> > > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher Shannon <ch...@gmail.com>.
I'm +1 to using some kind of wiki so if we can't use Confluence then GH
sounds fine to me. Do we need to take a formal vote for using the Github
wiki or is there enough consensus already?
On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts <dd...@gmail.com> wrote:
> +1 for the GH wiki with major discussions still being fed into, or
> originated on the mailing lists.
>
> As a side question, if there is a lengthy discussion on a GH issue, is it
> standard practice to just recap that in a mailing list message?
> Or is there a more "formal" inclusion process to follow?
>
>
> On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org> wrote:
>
> > I don't think the workflow I proposed about using PRs and discussion on
> > tickets, etc. and the accompanying arguments about keeping things
> > consolidated and accessible to potential contributors not participating
> on
> > GitHub, were really challenged at all. However, since I seem to be the
> only
> > one advocating for using the website, to keep things centralized, as per
> > previous attempts to consolidate documentation, I won't fight the use of
> > GitHub wiki. But I do want to make it clear that we're proceeding in that
> > direction under my objection (-0), and that I'm not convinced this is the
> > best path forward. Hopefully, I will be proven wrong in time.
> >
> > On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > can re-evaluate things once the Apache confluence issue is sorted out.
> > >
> > > Agreed.
> > >
> > > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> > >
> > > > I just tried (Wed, 3/15) and still received the same error. I asked
> on
> > > > the infra slack channel and they replied that they are still working
> to
> > > > determine what the issue is - signs are pointing to something inside
> of
> > > > confluence, but no progress.
> > > >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > > can re-evaluate things once the Apache confluence issue is sorted
> out.
> > > >
> > > > Ed Coleman
> > > >
> > > > -----Original Message-----
> > > > From: Dave Marion <dm...@gmail.com>
> > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > To: dev@accumulo.apache.org
> > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >
> > > > Looking at the Infra slack channel response, one of the responses in
> > the
> > > > channel said that "it's some sort of db corruption according to
> > > Atlassian".
> > > > Doesn't sound good....
> > > >
> > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com>
> > wrote:
> > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > unresolved
> > > > > and the only comment on the ticket is one that Ed added two days
> ago
> > > > > requesting an ACCUMULO wiki space.
> > > > >
> > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> > > > >
> > > > >> I do not see any comments in the infa slack channel - so no
> updates
> > > > >> for now.
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Dave Marion <dm...@gmail.com>
> > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > >> To: dev@accumulo.apache.org
> > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >>
> > > > >> Right, I was just curious if there was any follow-up as I think Ed
> > > > >> said that it was going to be discussed by the INFRA team
> yesterday.
> > > > >> There is at least one other recent ticket (
> > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> selfserve
> > > > >> had an issue and the INFRA team created the space manually.
> > > > >>
> > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org>
> > > > wrote:
> > > > >>
> > > > >> > You can track that issue at
> > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > >> >
> > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> dmarion18@gmail.com>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > Ed,
> > > > >> > >
> > > > >> > > Any update from INFRA on being able to create confluence
> > pages?
> > > > >> > >
> > > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <
> ctubbsii@apache.org
> > >
> > > > >> wrote:
> > > > >> > >
> > > > >> > > > We've definitely used the website for more than that. We use
> > it
> > > > >> > > > to document things for users, help developers know how to
> > > > >> > > > contribute, store drafts of designs, share user stories via
> > > > >> > > > blogs, do release announcements, and more. There's
> definitely
> > > > >> > > > space on the website to do this kind of thing, if we want
> to.
> > > > >> > > > We've used it that way before. If you only see it as a place
> > > > >> > > > "for user consumption after everything has been finalized",
> > > > >> > > > then you're missing out on the other ways we currently use
> the
> > > > >> > > > site, and the ways we've used it in
> > > > >> the past.
> > > > >> > > >
> > > > >> > > > With the website, most of the collaboration would happen in
> > the
> > > > >> > > > GH issues about proposed designs or changes to designs, just
> > > > >> > > > like we do today with code or other documentation, which
> > > > >> > > > everybody is used to. I agree it's not as good as Google
> Docs
> > > > >> > > > for on-the-fly comments/annotations, but I don't think
> > > > >> > > > Confluence or Wiki are as good as that either, and Google
> Docs
> > > > isn't really an option...
> > > > >> > > > unless you just want to link to it in the mailing list and
> > > > >> > > > stick to Google Docs from your personal Google account,
> until
> > > > >> > > > it's ready for publication, which would also be fine (any
> > > > >> > > > interested persons can simply request write access by
> replying
> > > > >> > > > to the message where
> > > > >> you shared the link)..
> > > > >> > > >
> > > > >> > > > We are a much smaller project than many others, and we have
> > > > >> > > > previously suffered from having stuff too spread out. Even
> if
> > > > >> > > > other projects find a separate space valuable for them, I'm
> > not
> > > > >> > > > sure it's best for the Accumulo project. While I think it's
> > > > >> > > > useful to examine what other projects do, I do think we
> should
> > > > >> > > > be careful to adopt anything just because others find it
> > > > convenient for them.
> > > > >> > > >
> > > > >> > > > Confluence is my second choice, but with a big gap between
> it
> > > > >> > > > and my first choice.
> > > > >> > > >
> > > > >> > > > On a personal note: I hate using Confluence, because I think
> > > > >> > > > the navigation is highly unintuitive, as is the permissions
> > > > >> > > > model, and I don't like the idea of learning yet another
> > > > >> > > > wiki-syntax (though I've read Confluence supports some
> limited
> > > > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I
> also
> > > > >> > > > do not want to set up custom notifications for watching yet
> > > > >> > > > another space. If we use Confluence, I will probably
> > contribute
> > > > >> > > > very infrequently there because of my frustrations with
> having
> > > > >> > > > used it before. However, that would be my choice, and should
> > > > >> > > > not be a reason the project chooses one over another. I'm
> > > > >> > > > sharing my personal opinion only because it is influencing
> my
> > > > >> > > > opinion about the website being more accessible, via our
> > > > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder how
> > > > >> > > > many other potential contributors would feel similarly. It's
> > > > >> > > > hard to know, since it seems like a lot of this is
> subjective,
> > > > >> > > > and is going to come down to a consensus of personal
> > > > >> preferences.
> > > > >> > > >
> > > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > > >> > > > <dm...@gmail.com>
> > > > >> > wrote:
> > > > >> > > > >
> > > > >> > > > > I don't see the website as an area where we would have
> > > > >> > > > > collaborative discussions about an idea. For example,
> making
> > > > >> > > > > comments and
> > > > >> > suggestions
> > > > >> > > > on
> > > > >> > > > > a document like you can do in Google Docs. I see the
> website
> > > > >> > > > > as a
> > > > >> > place
> > > > >> > > > > where items are documented for user consumption after
> > > > >> > > > > everything has
> > > > >> > been
> > > > >> > > > > finalized. I'm not trying to create a private discussion
> > > > >> > > > > area, I
> > > > >> > think
> > > > >> > > > > anyone can see the wiki (but I think anonymous comments
> are
> > > > >> > > > > disabled
> > > > >> > due
> > > > >> > > > to
> > > > >> > > > > spam issues). I see no issue with putting work-in-progress
> > > > >> > > > > documents
> > > > >> > on a
> > > > >> > > > > wiki and referencing them via emails to the dev list. I
> > think
> > > > >> > > > > this is
> > > > >> > > > done
> > > > >> > > > > in a lot of other projects. Non-committers that don't have
> > > > >> > > > > access to
> > > > >> > the
> > > > >> > > > > wiki and want to make comments, suggestions, and ask
> > > > >> > > > > questions can
> > > > >> > do so
> > > > >> > > > > via the mailing list. I think it's also possible that
> people
> > > > >> > > > > can get confluence accounts (see
> > > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > >> > > > > so if a non-committer wanted to participate they could.
> > > > >> > > > >
> > > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > > >> > > > > <ct...@apache.org>
> > > > >> > wrote:
> > > > >> > > > >
> > > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > >> > > > > > <dm...@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > I'm opposed to using the website for the reasons I
> > > > >> > > > > > > specified
> > > > >> > > > earlier, so
> > > > >> > > > > > it
> > > > >> > > > > >
> > > > >> > > > > > Your reasons that I saw were:
> > > > >> > > > > >
> > > > >> > > > > > > 1. I don't think internal design discussions should go
> > on
> > > > >> > > > > > > the
> > > > >> > project
> > > > >> > > > > > website.
> > > > >> > > > > >
> > > > >> > > > > > That doesn't look to me like a reason. That appears to
> > just
> > > > >> > > > > > be
> > > > >> > stating
> > > > >> > > > > > the conclusion. Did I miss your reason here?
> > > > >> > > > > >
> > > > >> > > > > > > 2. Changes to the design documents could not be seen
> by
> > > > >> > > > > > > others
> > > > >> > right
> > > > >> > > > > > away (IIRC changes to the website are built and
> available
> > > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > > >> > > > > > intervention is
> > > > >> > > > required
> > > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > > >> > > > > >
> > > > >> > > > > > What do you mean by "others" here? Do you mean "users",
> as
> > > > >> > > > > > opposed
> > > > >> > to
> > > > >> > > > > > "developers/contributors"? The ASF draws a distinction
> > > > >> > > > > > between "developers/contributors" and "users" as it
> > > > >> > > > > > pertains to official releases. Releases are intended to
> be
> > > > >> > > > > > consumed by users, and pre-release stuff is intended to
> be
> > > > >> > > > > > collaborative, open to all potential
> > > > >> > > > > > developers/contributors. Very very rarely are things
> > > > >> > > > > > reserved exclusively for committers. We don't even have
> a
> > > > >> > > > > > private committers space (the private mailing list is
> > > > >> > > > > > PMC-private, not committer-private). Having a
> distinction
> > > > >> > > > > > between users and
> > > > >> > developers
> > > > >> > > > > > doesn't mean we can't publish things on the website...
> it
> > > > >> > > > > > just
> > > > >> > means
> > > > >> > > > > > that we should be careful about how we do it, which is
> the
> > > > >> > > > > > same
> > > > >> > care
> > > > >> > > > > > we should take regardless of where we put it.
> > Specifically,
> > > > >> > > > > > the
> > > > >> > care
> > > > >> > > > > > we need to take is to avoid marketing pre-release
> content
> > > > >> > > > > > to
> > > > >> users.
> > > > >> > > > > > One way we can exercise this care for content on our
> > > > >> > > > > > website is
> > > > >> > that
> > > > >> > > > > > we can avoid sharing these unpolished designs by simply
> > not
> > > > >> > > > > > linking them on the site, or by placing them in an area
> > > > >> > > > > > that is clearly
> > > > >> > marked
> > > > >> > > > > > as intended for devs. But, we have no similar
> distinction
> > > > >> > > > > > between committers and non-committer devs for which we
> > > > >> > > > > > should avoid sharing pre-release content under
> > development.
> > > > >> > > > > > In fact, it is the
> > > > >> > opposite...
> > > > >> > > > > > we should be developing openly so as to allow room for
> > > > >> > non-committers
> > > > >> > > > > > to become committers through participation in
> development
> > > > >> > activities.
> > > > >> > > > > >
> > > > >> > > > > > As for the staging/publication of the website, that's
> just
> > > > >> > > > > > a
> > > > >> > mechanic
> > > > >> > > > > > for verifying the website isn't broken before we serve
> it.
> > > > >> > > > > > It's
> > > > >> > not a
> > > > >> > > > > > mechanism for keeping things internal vs. shared and
> > > > >> > > > > > doesn't have anything to do with the separation between
> > > > >> > > > > > devs and users. We
> > > > >> > already
> > > > >> > > > > > publish Draft contents to the website, as well as
> > > > >> > developer-specific
> > > > >> > > > > > documentation not intended for users.
> > > > >> > > > > >
> > > > >> > > > > > We've even specifically published work-in-progress
> design
> > > > >> > > > > > documents there, of the same type that seems to be the
> > > > >> > > > > > basis of this conversation (
> > > > >> https://accumulo.apache.org/design/system-snapshot).
> > > > >> > I
> > > > >> > > > > > would strongly prefer us to continue to do it this way,
> > > > >> > > > > > rather than create a new space, and have these kinds of
> > > > >> > > > > > things scattered in multiple places.
> > > > >> > > > > >
> > > > >> > > > > > If, on the other hand, you intend to say that these
> should
> > > > >> > > > > > be
> > > > >> > private
> > > > >> > > > > > because they aren't ready for other potential
> > contributors,
> > > > >> > > > > > then I would argue that we're an openly developed
> > project...
> > > > >> > > > > > if something isn't ready to be shared with other
> potential
> > > > >> > > > > > contributors / developers, such that you want to keep it
> > > > >> > > > > > internal to existing committers, then it's not ready to
> be
> > > > >> > > > > > contributed to the project at all... because we don't
> > > > >> > > > > > restrict collaboration to only existing committers. That
> > > > >> > > > > > would prevent others from participating and
> > > > >> > earning
> > > > >> > > > > > the merit to become committers, and that's not something
> > we
> > > > >> > > > > > should
> > > > >> > be
> > > > >> > > > > > doing. Anything that is okay to share with existing
> > > > >> > > > > > committers
> > > > >> > should
> > > > >> > > > > > be okay to share to other potential contributors who
> want
> > > > >> > > > > > to participate, and should be done in a space that
> allows
> > > > >> > > > > > them to do that. The website is a perfect space for
> that,
> > > > >> > > > > > and has everything
> > > > >> > we
> > > > >> > > > > > need. I'm actually not sure about Confluence... I
> suspect
> > > > >> > > > > > non-committers wouldn't be able to participate there
> > > > >> > > > > > because they probably can't get accounts for it.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > > looks like we need to
> > > > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious how
> > much
> > > > >> > > > > > > we
> > > > >> > need to
> > > > >> > > > use
> > > > >> > > > > > > the mailing list during
> > > > >> > > > > > > the design phase. We can announce meeting dates/times
> on
> > > > >> > > > > > > the
> > > > >> > mailing
> > > > >> > > > list
> > > > >> > > > > > > and post links to
> > > > >> > > > > > > meeting notes in Confluence. Ultimately, decisions
> made
> > > > >> > > > > > > by the
> > > > >> > people
> > > > >> > > > > > that
> > > > >> > > > > > > want to be involved
> > > > >> > > > > > > will turn into pull requests against the codebase
> which
> > > > >> > comitters can
> > > > >> > > > > > weigh
> > > > >> > > > > > > in on. When you say,
> > > > >> > > > > > > "... but decisions about those would still need to be
> > > > >> > > > > > > done on the
> > > > >> > > > mailing
> > > > >> > > > > > > list." Are you saying that we need to discuss every
> > > > >> > > > > > > single design decision on the mailing
> > > > >> > list?
> > > > >> > > > > >
> > > > >> > > > > > Yes and no. I am saying that decisions need to happen on
> > > > >> > > > > > the
> > > > >> > mailing
> > > > >> > > > > > list, but I agree with you that this can be satisfied
> > > > >> > > > > > through pull requests. I just wanted to emphasize that
> > > > >> > > > > > regardless of where we do that pre-decision
> collaboration,
> > > > >> > > > > > that collaboration should not be misconstrued as a
> > decision
> > > > >> > > > > > to
> > > > >> accept those ideas into the project.
> > > > >> > The
> > > > >> > > > > > decision occurs during the PR or other activity that
> > > > >> > > > > > interfaces
> > > > >> > with
> > > > >> > > > > > the mailing list, subsequent to the collaboration in the
> > > > >> > design/idea
> > > > >> > > > > > phase.
> > > > >> > > > > >
> > > > >> > > > > > As for the pre-decision collaboration space we're
> > > > >> > > > > > discussing, I
> > > > >> > just
> > > > >> > > > > > want to be careful that we're not creating such a space
> in
> > > > >> > > > > > an exclusionary way that allows only existing committers
> > to
> > > > >> > participate,
> > > > >> > > > > > that excludes other potential contributors. This is
> still
> > > > >> > > > > > an openly-developed project, and we should collaborate
> in
> > a
> > > > >> > > > > > space
> > > > >> > that is
> > > > >> > > > > > not exclusive to existing committers, but open to
> > > > >> > > > > > non-committer contributors and potential contributors as
> > > well.
> > > > >> > > > > > So, while we may
> > > > >> > want
> > > > >> > > > > > to keep a line separating dev activity from user
> > > > >> > > > > > consumption (an important separation that relates to
> > > > >> > > > > > official ASF releases), we
> > > > >> > should
> > > > >> > > > > > not be drawing a line between committer-devs as
> "internal"
> > > > >> > > > > > and contributor-devs as "external". The website, with
> its
> > > > >> > > > > > own issue tracker, the ability to render markdown, do
> > > > >> > > > > > reviews, and collaboratively edit, seems like the ideal
> > > > >> > > > > > place to me. We've used
> > > > >> > it
> > > > >> > > > > > before for the same purpose, and I think we should
> > continue
> > > > >> > > > > > to do
> > > > >> > so.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > >> > > > > > > <ctubbsii@apache.org
> > > > >> > >
> > > > >> > > > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > So, I agree a space would be helpful. Although it's
> > old
> > > > >> > > > > > > > school
> > > > >> > and
> > > > >> > > > > > > > inconvenient, the mailing list is the canonical
> place
> > > > >> > > > > > > > for
> > > > >> > > > discussion.
> > > > >> > > > > > > > We currently use GitHub issues a lot, but that's
> > copied
> > > > >> > > > > > > > to a
> > > > >> > > > mailing
> > > > >> > > > > > > > list (as is our old JIRA space), so if people want
> to
> > > > >> > participate
> > > > >> > > > > > > > without a GitHub account, they can still do that.
> > There
> > > > >> > > > > > > > are
> > > > >> > certain
> > > > >> > > > > > > > options that are perhaps less convenient, such as
> just
> > > > >> > > > > > > > using
> > > > >> > the
> > > > >> > > > > > > > mailing list and our dev SVN space, but still more
> > > > >> > > > > > > > appropriate
> > > > >> > than
> > > > >> > > > > > > > options that would be less ubiquitous for potential
> > > > >> > participants.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > > > >> > > > > > > > storing,
> > > > >> > editing,
> > > > >> > > > and
> > > > >> > > > > > > > collaborating on shared documents, but decisions
> about
> > > > >> > > > > > > > those
> > > > >> > would
> > > > >> > > > > > > > still need to be done on the mailing list. If I
> > > > >> > > > > > > > remember
> > > > >> > > > correctly, we
> > > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > > >> > > > > > > > maintained, so we abandoned it in
> > > > >> > > > favor
> > > > >> > > > > > > > of using the website for docs. I could be
> > > > >> > > > > > > > mis-remembering, but
> > > > >> > I
> > > > >> > > > think
> > > > >> > > > > > > > this is the case. It might explain why you can't
> > create
> > > > >> > > > > > > > a
> > > > >> > > > Confluence
> > > > >> > > > > > > > space.
> > > > >> > > > > > > >
> > > > >> > > > > > > > My preference would be to just use the website. I
> > think
> > > > >> > > > > > > > it's
> > > > >> > fine
> > > > >> > > > to
> > > > >> > > > > > > > have a dev / design area of the website, and we can
> > > > >> > > > > > > > discuss on
> > > > >> > > > GitHub
> > > > >> > > > > > > > issues for the accumulo-website repo. That is a bit
> > > > >> > > > > > > > less
> > > > >> > convenient
> > > > >> > > > > > > > than Confluence if it's used heavily, but it's more
> > > > >> > > > > > > > convenient
> > > > >> > in
> > > > >> > > > the
> > > > >> > > > > > > > sense that it's more accessible and fits more in
> line
> > > > >> > > > > > > > with our
> > > > >> > > > current
> > > > >> > > > > > > > mode of operation. Plus, when a document is final,
> > it's
> > > > >> > > > > > > > easy to
> > > > >> > > > link
> > > > >> > > > > > > > to from our documentation, without making users jump
> > to
> > > > >> > > > > > > > another service to view docs.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I would be opposed to using GitHub wiki or a new git
> > > repo.
> > > > >> > > > > > > > We
> > > > >> > have
> > > > >> > > > > > > > enough repos. Although it seems like they are free,
> > > > >> > > > > > > > there is
> > > > >> > still
> > > > >> > > > a
> > > > >> > > > > > > > lot of boilerplate work to maintain them, from
> > managing
> > > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> > > > >> > .asf.yaml, to
> > > > >> > > > > > > > README, to keeping copyright dates updated in the
> > > > >> > > > > > > > NOTICE file,
> > > > >> > and
> > > > >> > > > > > > > more.
> > > > >> > > > > > > >
> > > > >> > > > > > > > In summary, my preference:
> > > > >> > > > > > > >
> > > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
> > > > >> > > > > > > > issues and
> > > > >> > > > mailing
> > > > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss on
> > > > >> > > > > > > > mailing list (prefer over other
> > > > >> > options,
> > > > >> > > > but
> > > > >> > > > > > > > not a fan)
> > > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
> > > > >> > > > > > > > prefer not
> > > > >> > to use
> > > > >> > > > > > this
> > > > >> > > > > > > > option)
> > > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing
> > > > >> > > > > > > > list
> > > > >> > (strongly
> > > > >> > > > > > > > prefer not to use this option)
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > > >> > edcoleman@apache.org>
> > > > >> > > > > > wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Currently, asf cannot create new wiki's because
> of a
> > > > >> > Confluence
> > > > >> > > > > > issue (
> > > > >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291)
> I
> > > > >> > > > > > > > chatted
> > > > >> > with
> > > > >> > > > > > infra
> > > > >> > > > > > > > and in response they created that issue.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > To expand on this discussion, I would like to toss
> > > > >> > > > > > > > > out
> > > > >> > another
> > > > >> > > > > > > > alternative to discuss / explore. What if we used a
> > > > >> > > > > > > > separate
> > > > >> > > > GitHub
> > > > >> > > > > > > > project, something like Accumulo-Design, just like
> > > > >> > accumulo-proxy
> > > > >> > > > and
> > > > >> > > > > > > > accumulo-examples. As a separate project, it would
> be
> > > > >> > available
> > > > >> > > > for
> > > > >> > > > > > > > collaboration for the community, but remain separate
> > > > >> > > > > > > > from main
> > > > >> > > > project
> > > > >> > > > > > and
> > > > >> > > > > > > > the website to keep current code / documentation /
> > > > >> > > > > > > > design
> > > > >> > clearly
> > > > >> > > > > > separate
> > > > >> > > > > > > > from speculative design discussions. As a project:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > - document history would be preserved with git
> > commit
> > > > >> > history.
> > > > >> > > > > > > > > - document collaboration could be done with normal
> > PR
> > > > >> > > > submissions /
> > > > >> > > > > > > > reviews.
> > > > >> > > > > > > > > - issues could be used to discuss design aspects,
> > > > >> > > > > > > > > capturing
> > > > >> > the
> > > > >> > > > > > comment
> > > > >> > > > > > > > history.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > The biggest downside is that it would be yet
> another
> > > > >> > > > > > > > > project
> > > > >> > to
> > > > >> > > > > > follow /
> > > > >> > > > > > > > track.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > For me, I think the issue is that we need a
> public,
> > > > >> > collaborative
> > > > >> > > > > > space
> > > > >> > > > > > > > to hold design discussions. Neither the main project
> > or
> > > > >> > > > > > > > the
> > > > >> > > > web-site
> > > > >> > > > > > seem
> > > > >> > > > > > > > quite appropriate and Confluence seems to lack the
> > > > >> > collaboration
> > > > >> > > > that
> > > > >> > > > > > can
> > > > >> > > > > > > > be achieved with github.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > We need a space to capture the redesign and
> whatever
> > > > >> > > > > > > > > we
> > > > >> > select
> > > > >> > > > can be
> > > > >> > > > > > > > made to work - I'm just wondering what provides the
> > > > >> > > > > > > > easiest
> > > > >> > forum
> > > > >> > > > to
> > > > >> > > > > > build
> > > > >> > > > > > > > a collaborative space for the Accumulo community.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Ed Coleman
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net
> wrote:
> > > > >> > > > > > > > > > Circling back on this issue - I agree that
> > comments
> > > > >> > > > > > > > > > and
> > > > >> > such
> > > > >> > > > make
> > > > >> > > > > > > > sense for internal design documents. I'm going to
> > > > >> > > > > > > > create an
> > > > >> > INFRA
> > > > >> > > > > > ticket
> > > > >> > > > > > > > for a cwiki space for Accumulo unless there are any
> > > > >> objections.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > -----Original Message-----
> > > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> > > asf.yaml?
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > As mentioned, wikis can provide a streamlined
> > > > >> > > > > > > > > > collaborative
> > > > >> > > > editing
> > > > >> > > > > > > > workflow that's less labor intensive than updating a
> > > > >> website.
> > > > >> > They
> > > > >> > > > can
> > > > >> > > > > > > > promote collaboration by providing specific tooling
> to
> > > > >> > > > > > > > support
> > > > >> > > > > > comments,
> > > > >> > > > > > > > revisions and iteration.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > In terms of preservation, GH wikis act just like
> > > > >> > > > > > > > > > any other
> > > > >> > Git
> > > > >> > > > > > > > repository, with a remote at (for example)
> > > git@github.com
> > > > :
> > > > >> > > > > > > > apache/accumulo.wiki.git
> > > > >> > > > > > > > > > IIRC the pages are just GH flavored markdown.
> > There
> > > > >> > > > > > > > > > are at
> > > > >> > > > least a
> > > > >> > > > > > few
> > > > >> > > > > > > > Apache projects using them.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > However, GH wikis lack some features that I feel
> > > > >> > > > > > > > > > are
> > > > >> > important
> > > > >> > > > to
> > > > >> > > > > > > > support collaborative authoring. For example, the
> > > > >> > > > > > > > ability to
> > > > >> > > > comment
> > > > >> > > > > > and
> > > > >> > > > > > > > discuss specific passages in a document is a feature
> > > > >> > > > > > > > that's
> > > > >> > > > present in
> > > > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate
> this
> > > > >> > > > > > > > this in
> > > > >> > my
> > > > >> > > > google
> > > > >> > > > > > > > docs and office workflows, so expect that it would
> be
> > > > >> > > > > > > > useful
> > > > >> > for
> > > > >> > > > > > Accumulo
> > > > >> > > > > > > > design discussions too.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > > >> > > > kturner@apache.org>
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > > I would like to try a wiki for design
> documents,
> > > > >> > > > > > > > > > > I think
> > > > >> > it
> > > > >> > > > > > would be
> > > > >> > > > > > > > > > > less cumbersome than the website and we can
> > > > >> > > > > > > > > > > always link
> > > > >> > from
> > > > >> > > > the
> > > > >> > > > > > > > > > > website and issues to the wiki. I think its
> ok
> > > > >> > > > > > > > > > > to give
> > > > >> > it a
> > > > >> > > > try
> > > > >> > > > > > and
> > > > >> > > > > > > > > > > abandon it in the future, if abandoned would
> > just
> > > > >> > > > > > > > > > > need to
> > > > >> > > > > > properly
> > > > >> > > > > > > > > > > communicate that. The content should be
> > archived
> > > > >> > > > > > > > > > > in
> > > > >> > Apache
> > > > >> > > > > > > > > > > infrastructure, so if GH wiki does not do that
> > > > >> > > > > > > > > > > then we
> > > > >> > should
> > > > >> > > > > > not use
> > > > >> > > > > > > > > > > it. If GH wiki is not an option then could
> try
> > > > cwiki.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > >> > > > > > > > > > > <dl...@comcast.net>
> > > > >> > > > wrote:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I reverted the change. I didn't think it
> would
> > > > >> > > > > > > > > > > > be a big
> > > > >> > > > deal,
> > > > >> > > > > > but
> > > > >> > > > > > > > if
> > > > >> > > > > > > > > > > > it
> > > > >> > > > > > > > > > > requires discussion, then let's discuss it.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I'm looking for a place to host information
> > > > >> > > > > > > > > > > > related to
> > > > >> > > > internal
> > > > >> > > > > > > > > > > > design
> > > > >> > > > > > > > > > > discussions. I envision these to be living
> > > > >> > > > > > > > > > > documents that
> > > > >> > > > will be
> > > > >> > > > > > > > > > > updated over time as the design/implementation
> > > > >> > progresses and
> > > > >> > > > > > that
> > > > >> > > > > > > > > > > other committers will be able to comment on
> and
> > > > >> > > > > > > > > > > edit. I
> > > > >> > don't
> > > > >> > > > > > feel
> > > > >> > > > > > > > > > > that the website is the correct place for this
> > > > >> because:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > 1. I don't think internal design
> discussions
> > > > >> > > > > > > > > > > > should
> > > > >> > go
> > > > >> > > > on the
> > > > >> > > > > > > > > > > > project
> > > > >> > > > > > > > > > > website.
> > > > >> > > > > > > > > > > > 2. Changes to the design documents could
> not
> > > > >> > > > > > > > > > > > be seen
> > > > >> > by
> > > > >> > > > > > others
> > > > >> > > > > > > > > > > > right
> > > > >> > > > > > > > > > > away (IIRC changes to the website are built
> and
> > > > >> > available at
> > > > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but
> human
> > > > >> > intervention
> > > > >> > > > is
> > > > >> > > > > > > > > > > required to publish it at
> > > > >> https://accumulo.apache.org/).
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I looked in the INFRA issues and other
> > projects
> > > > >> > > > > > > > > > > > are
> > > > >> > using
> > > > >> > > > the
> > > > >> > > > > > GH
> > > > >> > > > > > > > > > > > Wiki
> > > > >> > > > > > > > > > > feature and I saw no mention of backing it up
> or
> > > > >> > > > > > > > > > > the
> > > > >> > > > requirement
> > > > >> > > > > > to
> > > > >> > > > > > > > do
> > > > >> > > > > > > > > > > so (maybe they rely on GitHub backing it up?).
> > It
> > > > >> > > > > > > > > > > does
> > > > >> > appear
> > > > >> > > > > > that we
> > > > >> > > > > > > > > > > would need an INFRA ticket so that they can
> > > > >> > > > > > > > > > > modify the
> > > > >> > GitHub
> > > > >> > > > > > project
> > > > >> > > > > > > > > > > settings to lock the GitHub wiki down so that
> > > > >> > > > > > > > > > > only
> > > > >> > > > committers can
> > > > >> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable,
> > then
> > > > >> > > > > > > > > > > I think
> > > > >> > > > Apache
> > > > >> > > > > > > > > > > Confluence (
> > > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> > acceptable
> > > > >> > > > alternative.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > -----Original Message-----
> > > > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > >> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> > > > >> > > > > > > > > > > > Enable
> > > > >> > Github
> > > > >> > > > > > wiki in
> > > > >> > > > > > > > > > > asf.yaml
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > I don't recall a discussion about this
> change,
> > > > >> > > > > > > > > > > > but I
> > > > >> > think
> > > > >> > > > it
> > > > >> > > > > > goes
> > > > >> > > > > > > > > > > against previous efforts to make the website
> the
> > > > >> > > > > > > > > > > one
> > > > >> > > > canonical
> > > > >> > > > > > > > > > > location for our documentation. I don't even
> > > > >> > > > > > > > > > > think infra
> > > > >> > is
> > > > >> > > > > > backing
> > > > >> > > > > > > > up
> > > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a record
> > of
> > > > >> > > > > > > > > > > the
> > > > >> > wiki
> > > > >> > > > > > contents
> > > > >> > > > > > > > in
> > > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed
> > up
> > > > >> > > > > > > > > > > to
> > > > >> > GitBox
> > > > >> > > > and
> > > > >> > > > > > the
> > > > >> > > > > > > > > > > issue tracker, which CCs the notifications
> > list).
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > In short, I think this should be reverted
> and
> > > > >> > > > > > > > > > > > we
> > > > >> > should not
> > > > >> > > > > > use the
> > > > >> > > > > > > > > > > GitHub wiki. If we need to store documents in
> a
> > > > >> > > > > > > > > > > version
> > > > >> > > > > > controlled
> > > > >> > > > > > > > > > > way, we can store them on the website, or in
> our
> > > > >> > project's
> > > > >> > > > SVN
> > > > >> > > > > > dev
> > > > >> > > > > > > > > > > space. The wiki is just another place people
> > > > >> > > > > > > > > > > would have
> > > > >> > to
> > > > >> > > > > > follow if
> > > > >> > > > > > > > > > > they want to participate, and I don't think
> that
> > > > >> > > > > > > > > > > serves
> > > > >> > us.
> > > > >> > > > > > > > Therefore,
> > > > >> > > > > > > > > > > I think we shouldn't use it.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > > >> > > > > > > > > > > > <dl...@apache.org>
> > > > >> > wrote:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > This is an automated email from the ASF
> > > > >> > > > > > > > > > > > > dual-hosted
> > > > >> > git
> > > > >> > > > > > > > repository.
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
> > > > >> > > > > > > > > > > > > repository
> > > > >> > > > > > > > > > > > >
> > https://gitbox.apache.org/repos/asf/accumulo.
> > > > >> > > > > > > > > > > > > git
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > The following commit(s) were added to
> > > > >> > refs/heads/main by
> > > > >> > > > this
> > > > >> > > > > > > > push:
> > > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> > > > >> > > > > > > > > > > > > asf.yaml
> > > > >> > > > > > ae8a817e7b is
> > > > >> > > > > > > > > > > > > described below
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > commit
> > > > >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > >> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > >> > > > > > > > > > > > > ---
> > > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > > >> > > > > > > > > > > > > deletion(-)
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > >> > > > > > bc2c943e82..08aa357082
> > > > >> > > > > > > > > > > > > 100644
> > > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > >> > > > > > > > > > > > > - big-data
> > > > >> > > > > > > > > > > > > - hacktoberfest
> > > > >> > > > > > > > > > > > > features:
> > > > >> > > > > > > > > > > > > - wiki: false
> > > > >> > > > > > > > > > > > > + wiki: true
> > > > >> > > > > > > > > > > > > issues: true
> > > > >> > > > > > > > > > > > > projects: true
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > >
> > > > >> > > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Daniel Roberts <dd...@gmail.com>.
+1 for the GH wiki with major discussions still being fed into, or
originated on the mailing lists.
As a side question, if there is a lengthy discussion on a GH issue, is it
standard practice to just recap that in a mailing list message?
Or is there a more "formal" inclusion process to follow?
On Wed, Mar 15, 2023 at 1:39 PM Christopher <ct...@apache.org> wrote:
> I don't think the workflow I proposed about using PRs and discussion on
> tickets, etc. and the accompanying arguments about keeping things
> consolidated and accessible to potential contributors not participating on
> GitHub, were really challenged at all. However, since I seem to be the only
> one advocating for using the website, to keep things centralized, as per
> previous attempts to consolidate documentation, I won't fight the use of
> GitHub wiki. But I do want to make it clear that we're proceeding in that
> direction under my objection (-0), and that I'm not convinced this is the
> best path forward. Hopefully, I will be proven wrong in time.
>
> On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
>
> > > At this point, I think we should move forward with a GH wiki and then
> we
> > can re-evaluate things once the Apache confluence issue is sorted out.
> >
> > Agreed.
> >
> > On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> >
> > > I just tried (Wed, 3/15) and still received the same error. I asked on
> > > the infra slack channel and they replied that they are still working to
> > > determine what the issue is - signs are pointing to something inside of
> > > confluence, but no progress.
> > >
> > > At this point, I think we should move forward with a GH wiki and then
> we
> > > can re-evaluate things once the Apache confluence issue is sorted out.
> > >
> > > Ed Coleman
> > >
> > > -----Original Message-----
> > > From: Dave Marion <dm...@gmail.com>
> > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > To: dev@accumulo.apache.org
> > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > >
> > > Looking at the Infra slack channel response, one of the responses in
> the
> > > channel said that "it's some sort of db corruption according to
> > Atlassian".
> > > Doesn't sound good....
> > >
> > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com>
> wrote:
> > >
> > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> unresolved
> > > > and the only comment on the ticket is one that Ed added two days ago
> > > > requesting an ACCUMULO wiki space.
> > > >
> > > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> > > >
> > > >> I do not see any comments in the infa slack channel - so no updates
> > > >> for now.
> > > >>
> > > >> -----Original Message-----
> > > >> From: Dave Marion <dm...@gmail.com>
> > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > >> To: dev@accumulo.apache.org
> > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >>
> > > >> Right, I was just curious if there was any follow-up as I think Ed
> > > >> said that it was going to be discussed by the INFRA team yesterday.
> > > >> There is at least one other recent ticket (
> > > >> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve
> > > >> had an issue and the INFRA team created the space manually.
> > > >>
> > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org>
> > > wrote:
> > > >>
> > > >> > You can track that issue at
> > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > >> >
> > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com>
> > > >> wrote:
> > > >> > >
> > > >> > > Ed,
> > > >> > >
> > > >> > > Any update from INFRA on being able to create confluence
> pages?
> > > >> > >
> > > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ctubbsii@apache.org
> >
> > > >> wrote:
> > > >> > >
> > > >> > > > We've definitely used the website for more than that. We use
> it
> > > >> > > > to document things for users, help developers know how to
> > > >> > > > contribute, store drafts of designs, share user stories via
> > > >> > > > blogs, do release announcements, and more. There's definitely
> > > >> > > > space on the website to do this kind of thing, if we want to.
> > > >> > > > We've used it that way before. If you only see it as a place
> > > >> > > > "for user consumption after everything has been finalized",
> > > >> > > > then you're missing out on the other ways we currently use the
> > > >> > > > site, and the ways we've used it in
> > > >> the past.
> > > >> > > >
> > > >> > > > With the website, most of the collaboration would happen in
> the
> > > >> > > > GH issues about proposed designs or changes to designs, just
> > > >> > > > like we do today with code or other documentation, which
> > > >> > > > everybody is used to. I agree it's not as good as Google Docs
> > > >> > > > for on-the-fly comments/annotations, but I don't think
> > > >> > > > Confluence or Wiki are as good as that either, and Google Docs
> > > isn't really an option...
> > > >> > > > unless you just want to link to it in the mailing list and
> > > >> > > > stick to Google Docs from your personal Google account, until
> > > >> > > > it's ready for publication, which would also be fine (any
> > > >> > > > interested persons can simply request write access by replying
> > > >> > > > to the message where
> > > >> you shared the link)..
> > > >> > > >
> > > >> > > > We are a much smaller project than many others, and we have
> > > >> > > > previously suffered from having stuff too spread out. Even if
> > > >> > > > other projects find a separate space valuable for them, I'm
> not
> > > >> > > > sure it's best for the Accumulo project. While I think it's
> > > >> > > > useful to examine what other projects do, I do think we should
> > > >> > > > be careful to adopt anything just because others find it
> > > convenient for them.
> > > >> > > >
> > > >> > > > Confluence is my second choice, but with a big gap between it
> > > >> > > > and my first choice.
> > > >> > > >
> > > >> > > > On a personal note: I hate using Confluence, because I think
> > > >> > > > the navigation is highly unintuitive, as is the permissions
> > > >> > > > model, and I don't like the idea of learning yet another
> > > >> > > > wiki-syntax (though I've read Confluence supports some limited
> > > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I also
> > > >> > > > do not want to set up custom notifications for watching yet
> > > >> > > > another space. If we use Confluence, I will probably
> contribute
> > > >> > > > very infrequently there because of my frustrations with having
> > > >> > > > used it before. However, that would be my choice, and should
> > > >> > > > not be a reason the project chooses one over another. I'm
> > > >> > > > sharing my personal opinion only because it is influencing my
> > > >> > > > opinion about the website being more accessible, via our
> > > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder how
> > > >> > > > many other potential contributors would feel similarly. It's
> > > >> > > > hard to know, since it seems like a lot of this is subjective,
> > > >> > > > and is going to come down to a consensus of personal
> > > >> preferences.
> > > >> > > >
> > > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > > >> > > > <dm...@gmail.com>
> > > >> > wrote:
> > > >> > > > >
> > > >> > > > > I don't see the website as an area where we would have
> > > >> > > > > collaborative discussions about an idea. For example, making
> > > >> > > > > comments and
> > > >> > suggestions
> > > >> > > > on
> > > >> > > > > a document like you can do in Google Docs. I see the website
> > > >> > > > > as a
> > > >> > place
> > > >> > > > > where items are documented for user consumption after
> > > >> > > > > everything has
> > > >> > been
> > > >> > > > > finalized. I'm not trying to create a private discussion
> > > >> > > > > area, I
> > > >> > think
> > > >> > > > > anyone can see the wiki (but I think anonymous comments are
> > > >> > > > > disabled
> > > >> > due
> > > >> > > > to
> > > >> > > > > spam issues). I see no issue with putting work-in-progress
> > > >> > > > > documents
> > > >> > on a
> > > >> > > > > wiki and referencing them via emails to the dev list. I
> think
> > > >> > > > > this is
> > > >> > > > done
> > > >> > > > > in a lot of other projects. Non-committers that don't have
> > > >> > > > > access to
> > > >> > the
> > > >> > > > > wiki and want to make comments, suggestions, and ask
> > > >> > > > > questions can
> > > >> > do so
> > > >> > > > > via the mailing list. I think it's also possible that people
> > > >> > > > > can get confluence accounts (see
> > > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > >> > > > > so if a non-committer wanted to participate they could.
> > > >> > > > >
> > > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > > >> > > > > <ct...@apache.org>
> > > >> > wrote:
> > > >> > > > >
> > > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > >> > > > > > <dm...@gmail.com>
> > > >> > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > > I'm opposed to using the website for the reasons I
> > > >> > > > > > > specified
> > > >> > > > earlier, so
> > > >> > > > > > it
> > > >> > > > > >
> > > >> > > > > > Your reasons that I saw were:
> > > >> > > > > >
> > > >> > > > > > > 1. I don't think internal design discussions should go
> on
> > > >> > > > > > > the
> > > >> > project
> > > >> > > > > > website.
> > > >> > > > > >
> > > >> > > > > > That doesn't look to me like a reason. That appears to
> just
> > > >> > > > > > be
> > > >> > stating
> > > >> > > > > > the conclusion. Did I miss your reason here?
> > > >> > > > > >
> > > >> > > > > > > 2. Changes to the design documents could not be seen by
> > > >> > > > > > > others
> > > >> > right
> > > >> > > > > > away (IIRC changes to the website are built and available
> > > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > > >> > > > > > intervention is
> > > >> > > > required
> > > >> > > > > > to publish it at https://accumulo.apache.org/).
> > > >> > > > > >
> > > >> > > > > > What do you mean by "others" here? Do you mean "users", as
> > > >> > > > > > opposed
> > > >> > to
> > > >> > > > > > "developers/contributors"? The ASF draws a distinction
> > > >> > > > > > between "developers/contributors" and "users" as it
> > > >> > > > > > pertains to official releases. Releases are intended to be
> > > >> > > > > > consumed by users, and pre-release stuff is intended to be
> > > >> > > > > > collaborative, open to all potential
> > > >> > > > > > developers/contributors. Very very rarely are things
> > > >> > > > > > reserved exclusively for committers. We don't even have a
> > > >> > > > > > private committers space (the private mailing list is
> > > >> > > > > > PMC-private, not committer-private). Having a distinction
> > > >> > > > > > between users and
> > > >> > developers
> > > >> > > > > > doesn't mean we can't publish things on the website... it
> > > >> > > > > > just
> > > >> > means
> > > >> > > > > > that we should be careful about how we do it, which is the
> > > >> > > > > > same
> > > >> > care
> > > >> > > > > > we should take regardless of where we put it.
> Specifically,
> > > >> > > > > > the
> > > >> > care
> > > >> > > > > > we need to take is to avoid marketing pre-release content
> > > >> > > > > > to
> > > >> users.
> > > >> > > > > > One way we can exercise this care for content on our
> > > >> > > > > > website is
> > > >> > that
> > > >> > > > > > we can avoid sharing these unpolished designs by simply
> not
> > > >> > > > > > linking them on the site, or by placing them in an area
> > > >> > > > > > that is clearly
> > > >> > marked
> > > >> > > > > > as intended for devs. But, we have no similar distinction
> > > >> > > > > > between committers and non-committer devs for which we
> > > >> > > > > > should avoid sharing pre-release content under
> development.
> > > >> > > > > > In fact, it is the
> > > >> > opposite...
> > > >> > > > > > we should be developing openly so as to allow room for
> > > >> > non-committers
> > > >> > > > > > to become committers through participation in development
> > > >> > activities.
> > > >> > > > > >
> > > >> > > > > > As for the staging/publication of the website, that's just
> > > >> > > > > > a
> > > >> > mechanic
> > > >> > > > > > for verifying the website isn't broken before we serve it.
> > > >> > > > > > It's
> > > >> > not a
> > > >> > > > > > mechanism for keeping things internal vs. shared and
> > > >> > > > > > doesn't have anything to do with the separation between
> > > >> > > > > > devs and users. We
> > > >> > already
> > > >> > > > > > publish Draft contents to the website, as well as
> > > >> > developer-specific
> > > >> > > > > > documentation not intended for users.
> > > >> > > > > >
> > > >> > > > > > We've even specifically published work-in-progress design
> > > >> > > > > > documents there, of the same type that seems to be the
> > > >> > > > > > basis of this conversation (
> > > >> https://accumulo.apache.org/design/system-snapshot).
> > > >> > I
> > > >> > > > > > would strongly prefer us to continue to do it this way,
> > > >> > > > > > rather than create a new space, and have these kinds of
> > > >> > > > > > things scattered in multiple places.
> > > >> > > > > >
> > > >> > > > > > If, on the other hand, you intend to say that these should
> > > >> > > > > > be
> > > >> > private
> > > >> > > > > > because they aren't ready for other potential
> contributors,
> > > >> > > > > > then I would argue that we're an openly developed
> project...
> > > >> > > > > > if something isn't ready to be shared with other potential
> > > >> > > > > > contributors / developers, such that you want to keep it
> > > >> > > > > > internal to existing committers, then it's not ready to be
> > > >> > > > > > contributed to the project at all... because we don't
> > > >> > > > > > restrict collaboration to only existing committers. That
> > > >> > > > > > would prevent others from participating and
> > > >> > earning
> > > >> > > > > > the merit to become committers, and that's not something
> we
> > > >> > > > > > should
> > > >> > be
> > > >> > > > > > doing. Anything that is okay to share with existing
> > > >> > > > > > committers
> > > >> > should
> > > >> > > > > > be okay to share to other potential contributors who want
> > > >> > > > > > to participate, and should be done in a space that allows
> > > >> > > > > > them to do that. The website is a perfect space for that,
> > > >> > > > > > and has everything
> > > >> > we
> > > >> > > > > > need. I'm actually not sure about Confluence... I suspect
> > > >> > > > > > non-committers wouldn't be able to participate there
> > > >> > > > > > because they probably can't get accounts for it.
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > > looks like we need to
> > > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious how
> much
> > > >> > > > > > > we
> > > >> > need to
> > > >> > > > use
> > > >> > > > > > > the mailing list during
> > > >> > > > > > > the design phase. We can announce meeting dates/times on
> > > >> > > > > > > the
> > > >> > mailing
> > > >> > > > list
> > > >> > > > > > > and post links to
> > > >> > > > > > > meeting notes in Confluence. Ultimately, decisions made
> > > >> > > > > > > by the
> > > >> > people
> > > >> > > > > > that
> > > >> > > > > > > want to be involved
> > > >> > > > > > > will turn into pull requests against the codebase which
> > > >> > comitters can
> > > >> > > > > > weigh
> > > >> > > > > > > in on. When you say,
> > > >> > > > > > > "... but decisions about those would still need to be
> > > >> > > > > > > done on the
> > > >> > > > mailing
> > > >> > > > > > > list." Are you saying that we need to discuss every
> > > >> > > > > > > single design decision on the mailing
> > > >> > list?
> > > >> > > > > >
> > > >> > > > > > Yes and no. I am saying that decisions need to happen on
> > > >> > > > > > the
> > > >> > mailing
> > > >> > > > > > list, but I agree with you that this can be satisfied
> > > >> > > > > > through pull requests. I just wanted to emphasize that
> > > >> > > > > > regardless of where we do that pre-decision collaboration,
> > > >> > > > > > that collaboration should not be misconstrued as a
> decision
> > > >> > > > > > to
> > > >> accept those ideas into the project.
> > > >> > The
> > > >> > > > > > decision occurs during the PR or other activity that
> > > >> > > > > > interfaces
> > > >> > with
> > > >> > > > > > the mailing list, subsequent to the collaboration in the
> > > >> > design/idea
> > > >> > > > > > phase.
> > > >> > > > > >
> > > >> > > > > > As for the pre-decision collaboration space we're
> > > >> > > > > > discussing, I
> > > >> > just
> > > >> > > > > > want to be careful that we're not creating such a space in
> > > >> > > > > > an exclusionary way that allows only existing committers
> to
> > > >> > participate,
> > > >> > > > > > that excludes other potential contributors. This is still
> > > >> > > > > > an openly-developed project, and we should collaborate in
> a
> > > >> > > > > > space
> > > >> > that is
> > > >> > > > > > not exclusive to existing committers, but open to
> > > >> > > > > > non-committer contributors and potential contributors as
> > well.
> > > >> > > > > > So, while we may
> > > >> > want
> > > >> > > > > > to keep a line separating dev activity from user
> > > >> > > > > > consumption (an important separation that relates to
> > > >> > > > > > official ASF releases), we
> > > >> > should
> > > >> > > > > > not be drawing a line between committer-devs as "internal"
> > > >> > > > > > and contributor-devs as "external". The website, with its
> > > >> > > > > > own issue tracker, the ability to render markdown, do
> > > >> > > > > > reviews, and collaboratively edit, seems like the ideal
> > > >> > > > > > place to me. We've used
> > > >> > it
> > > >> > > > > > before for the same purpose, and I think we should
> continue
> > > >> > > > > > to do
> > > >> > so.
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > >
> > > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > >> > > > > > > <ctubbsii@apache.org
> > > >> > >
> > > >> > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > > > So, I agree a space would be helpful. Although it's
> old
> > > >> > > > > > > > school
> > > >> > and
> > > >> > > > > > > > inconvenient, the mailing list is the canonical place
> > > >> > > > > > > > for
> > > >> > > > discussion.
> > > >> > > > > > > > We currently use GitHub issues a lot, but that's
> copied
> > > >> > > > > > > > to a
> > > >> > > > mailing
> > > >> > > > > > > > list (as is our old JIRA space), so if people want to
> > > >> > participate
> > > >> > > > > > > > without a GitHub account, they can still do that.
> There
> > > >> > > > > > > > are
> > > >> > certain
> > > >> > > > > > > > options that are perhaps less convenient, such as just
> > > >> > > > > > > > using
> > > >> > the
> > > >> > > > > > > > mailing list and our dev SVN space, but still more
> > > >> > > > > > > > appropriate
> > > >> > than
> > > >> > > > > > > > options that would be less ubiquitous for potential
> > > >> > participants.
> > > >> > > > > > > >
> > > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > > >> > > > > > > > storing,
> > > >> > editing,
> > > >> > > > and
> > > >> > > > > > > > collaborating on shared documents, but decisions about
> > > >> > > > > > > > those
> > > >> > would
> > > >> > > > > > > > still need to be done on the mailing list. If I
> > > >> > > > > > > > remember
> > > >> > > > correctly, we
> > > >> > > > > > > > used to have a Wiki space, prior to it being
> > > >> > > > > > > > transferred to Confluence, but it was poorly
> > > >> > > > > > > > maintained, so we abandoned it in
> > > >> > > > favor
> > > >> > > > > > > > of using the website for docs. I could be
> > > >> > > > > > > > mis-remembering, but
> > > >> > I
> > > >> > > > think
> > > >> > > > > > > > this is the case. It might explain why you can't
> create
> > > >> > > > > > > > a
> > > >> > > > Confluence
> > > >> > > > > > > > space.
> > > >> > > > > > > >
> > > >> > > > > > > > My preference would be to just use the website. I
> think
> > > >> > > > > > > > it's
> > > >> > fine
> > > >> > > > to
> > > >> > > > > > > > have a dev / design area of the website, and we can
> > > >> > > > > > > > discuss on
> > > >> > > > GitHub
> > > >> > > > > > > > issues for the accumulo-website repo. That is a bit
> > > >> > > > > > > > less
> > > >> > convenient
> > > >> > > > > > > > than Confluence if it's used heavily, but it's more
> > > >> > > > > > > > convenient
> > > >> > in
> > > >> > > > the
> > > >> > > > > > > > sense that it's more accessible and fits more in line
> > > >> > > > > > > > with our
> > > >> > > > current
> > > >> > > > > > > > mode of operation. Plus, when a document is final,
> it's
> > > >> > > > > > > > easy to
> > > >> > > > link
> > > >> > > > > > > > to from our documentation, without making users jump
> to
> > > >> > > > > > > > another service to view docs.
> > > >> > > > > > > >
> > > >> > > > > > > > I would be opposed to using GitHub wiki or a new git
> > repo.
> > > >> > > > > > > > We
> > > >> > have
> > > >> > > > > > > > enough repos. Although it seems like they are free,
> > > >> > > > > > > > there is
> > > >> > still
> > > >> > > > a
> > > >> > > > > > > > lot of boilerplate work to maintain them, from
> managing
> > > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> > > >> > .asf.yaml, to
> > > >> > > > > > > > README, to keeping copyright dates updated in the
> > > >> > > > > > > > NOTICE file,
> > > >> > and
> > > >> > > > > > > > more.
> > > >> > > > > > > >
> > > >> > > > > > > > In summary, my preference:
> > > >> > > > > > > >
> > > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
> > > >> > > > > > > > issues and
> > > >> > > > mailing
> > > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss on
> > > >> > > > > > > > mailing list (prefer over other
> > > >> > options,
> > > >> > > > but
> > > >> > > > > > > > not a fan)
> > > >> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
> > > >> > > > > > > > prefer not
> > > >> > to use
> > > >> > > > > > this
> > > >> > > > > > > > option)
> > > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing
> > > >> > > > > > > > list
> > > >> > (strongly
> > > >> > > > > > > > prefer not to use this option)
> > > >> > > > > > > >
> > > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > > >> > edcoleman@apache.org>
> > > >> > > > > > wrote:
> > > >> > > > > > > > >
> > > >> > > > > > > > > Currently, asf cannot create new wiki's because of a
> > > >> > Confluence
> > > >> > > > > > issue (
> > > >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
> > > >> > > > > > > > chatted
> > > >> > with
> > > >> > > > > > infra
> > > >> > > > > > > > and in response they created that issue.
> > > >> > > > > > > > >
> > > >> > > > > > > > > To expand on this discussion, I would like to toss
> > > >> > > > > > > > > out
> > > >> > another
> > > >> > > > > > > > alternative to discuss / explore. What if we used a
> > > >> > > > > > > > separate
> > > >> > > > GitHub
> > > >> > > > > > > > project, something like Accumulo-Design, just like
> > > >> > accumulo-proxy
> > > >> > > > and
> > > >> > > > > > > > accumulo-examples. As a separate project, it would be
> > > >> > available
> > > >> > > > for
> > > >> > > > > > > > collaboration for the community, but remain separate
> > > >> > > > > > > > from main
> > > >> > > > project
> > > >> > > > > > and
> > > >> > > > > > > > the website to keep current code / documentation /
> > > >> > > > > > > > design
> > > >> > clearly
> > > >> > > > > > separate
> > > >> > > > > > > > from speculative design discussions. As a project:
> > > >> > > > > > > > >
> > > >> > > > > > > > > - document history would be preserved with git
> commit
> > > >> > history.
> > > >> > > > > > > > > - document collaboration could be done with normal
> PR
> > > >> > > > submissions /
> > > >> > > > > > > > reviews.
> > > >> > > > > > > > > - issues could be used to discuss design aspects,
> > > >> > > > > > > > > capturing
> > > >> > the
> > > >> > > > > > comment
> > > >> > > > > > > > history.
> > > >> > > > > > > > >
> > > >> > > > > > > > > The biggest downside is that it would be yet another
> > > >> > > > > > > > > project
> > > >> > to
> > > >> > > > > > follow /
> > > >> > > > > > > > track.
> > > >> > > > > > > > >
> > > >> > > > > > > > > For me, I think the issue is that we need a public,
> > > >> > collaborative
> > > >> > > > > > space
> > > >> > > > > > > > to hold design discussions. Neither the main project
> or
> > > >> > > > > > > > the
> > > >> > > > web-site
> > > >> > > > > > seem
> > > >> > > > > > > > quite appropriate and Confluence seems to lack the
> > > >> > collaboration
> > > >> > > > that
> > > >> > > > > > can
> > > >> > > > > > > > be achieved with github.
> > > >> > > > > > > > >
> > > >> > > > > > > > > We need a space to capture the redesign and whatever
> > > >> > > > > > > > > we
> > > >> > select
> > > >> > > > can be
> > > >> > > > > > > > made to work - I'm just wondering what provides the
> > > >> > > > > > > > easiest
> > > >> > forum
> > > >> > > > to
> > > >> > > > > > build
> > > >> > > > > > > > a collaborative space for the Accumulo community.
> > > >> > > > > > > > >
> > > >> > > > > > > > > Ed Coleman
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > >> > > > > > > > > > Circling back on this issue - I agree that
> comments
> > > >> > > > > > > > > > and
> > > >> > such
> > > >> > > > make
> > > >> > > > > > > > sense for internal design documents. I'm going to
> > > >> > > > > > > > create an
> > > >> > INFRA
> > > >> > > > > > ticket
> > > >> > > > > > > > for a cwiki space for Accumulo unless there are any
> > > >> objections.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > -----Original Message-----
> > > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > >> > > > > > > > > > To: dev@accumulo.apache.org
> > > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> > asf.yaml?
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > As mentioned, wikis can provide a streamlined
> > > >> > > > > > > > > > collaborative
> > > >> > > > editing
> > > >> > > > > > > > workflow that's less labor intensive than updating a
> > > >> website.
> > > >> > They
> > > >> > > > can
> > > >> > > > > > > > promote collaboration by providing specific tooling to
> > > >> > > > > > > > support
> > > >> > > > > > comments,
> > > >> > > > > > > > revisions and iteration.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > In terms of preservation, GH wikis act just like
> > > >> > > > > > > > > > any other
> > > >> > Git
> > > >> > > > > > > > repository, with a remote at (for example)
> > git@github.com
> > > :
> > > >> > > > > > > > apache/accumulo.wiki.git
> > > >> > > > > > > > > > IIRC the pages are just GH flavored markdown.
> There
> > > >> > > > > > > > > > are at
> > > >> > > > least a
> > > >> > > > > > few
> > > >> > > > > > > > Apache projects using them.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > However, GH wikis lack some features that I feel
> > > >> > > > > > > > > > are
> > > >> > important
> > > >> > > > to
> > > >> > > > > > > > support collaborative authoring. For example, the
> > > >> > > > > > > > ability to
> > > >> > > > comment
> > > >> > > > > > and
> > > >> > > > > > > > discuss specific passages in a document is a feature
> > > >> > > > > > > > that's
> > > >> > > > present in
> > > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate this
> > > >> > > > > > > > this in
> > > >> > my
> > > >> > > > google
> > > >> > > > > > > > docs and office workflows, so expect that it would be
> > > >> > > > > > > > useful
> > > >> > for
> > > >> > > > > > Accumulo
> > > >> > > > > > > > design discussions too.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > >> > > > kturner@apache.org>
> > > >> > > > > > > > wrote:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > > I would like to try a wiki for design documents,
> > > >> > > > > > > > > > > I think
> > > >> > it
> > > >> > > > > > would be
> > > >> > > > > > > > > > > less cumbersome than the website and we can
> > > >> > > > > > > > > > > always link
> > > >> > from
> > > >> > > > the
> > > >> > > > > > > > > > > website and issues to the wiki. I think its ok
> > > >> > > > > > > > > > > to give
> > > >> > it a
> > > >> > > > try
> > > >> > > > > > and
> > > >> > > > > > > > > > > abandon it in the future, if abandoned would
> just
> > > >> > > > > > > > > > > need to
> > > >> > > > > > properly
> > > >> > > > > > > > > > > communicate that. The content should be
> archived
> > > >> > > > > > > > > > > in
> > > >> > Apache
> > > >> > > > > > > > > > > infrastructure, so if GH wiki does not do that
> > > >> > > > > > > > > > > then we
> > > >> > should
> > > >> > > > > > not use
> > > >> > > > > > > > > > > it. If GH wiki is not an option then could try
> > > cwiki.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > >> > > > > > > > > > > <dl...@comcast.net>
> > > >> > > > wrote:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > I reverted the change. I didn't think it would
> > > >> > > > > > > > > > > > be a big
> > > >> > > > deal,
> > > >> > > > > > but
> > > >> > > > > > > > if
> > > >> > > > > > > > > > > > it
> > > >> > > > > > > > > > > requires discussion, then let's discuss it.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > I'm looking for a place to host information
> > > >> > > > > > > > > > > > related to
> > > >> > > > internal
> > > >> > > > > > > > > > > > design
> > > >> > > > > > > > > > > discussions. I envision these to be living
> > > >> > > > > > > > > > > documents that
> > > >> > > > will be
> > > >> > > > > > > > > > > updated over time as the design/implementation
> > > >> > progresses and
> > > >> > > > > > that
> > > >> > > > > > > > > > > other committers will be able to comment on and
> > > >> > > > > > > > > > > edit. I
> > > >> > don't
> > > >> > > > > > feel
> > > >> > > > > > > > > > > that the website is the correct place for this
> > > >> because:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > 1. I don't think internal design discussions
> > > >> > > > > > > > > > > > should
> > > >> > go
> > > >> > > > on the
> > > >> > > > > > > > > > > > project
> > > >> > > > > > > > > > > website.
> > > >> > > > > > > > > > > > 2. Changes to the design documents could not
> > > >> > > > > > > > > > > > be seen
> > > >> > by
> > > >> > > > > > others
> > > >> > > > > > > > > > > > right
> > > >> > > > > > > > > > > away (IIRC changes to the website are built and
> > > >> > available at
> > > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but human
> > > >> > intervention
> > > >> > > > is
> > > >> > > > > > > > > > > required to publish it at
> > > >> https://accumulo.apache.org/).
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > I looked in the INFRA issues and other
> projects
> > > >> > > > > > > > > > > > are
> > > >> > using
> > > >> > > > the
> > > >> > > > > > GH
> > > >> > > > > > > > > > > > Wiki
> > > >> > > > > > > > > > > feature and I saw no mention of backing it up or
> > > >> > > > > > > > > > > the
> > > >> > > > requirement
> > > >> > > > > > to
> > > >> > > > > > > > do
> > > >> > > > > > > > > > > so (maybe they rely on GitHub backing it up?).
> It
> > > >> > > > > > > > > > > does
> > > >> > appear
> > > >> > > > > > that we
> > > >> > > > > > > > > > > would need an INFRA ticket so that they can
> > > >> > > > > > > > > > > modify the
> > > >> > GitHub
> > > >> > > > > > project
> > > >> > > > > > > > > > > settings to lock the GitHub wiki down so that
> > > >> > > > > > > > > > > only
> > > >> > > > committers can
> > > >> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable,
> then
> > > >> > > > > > > > > > > I think
> > > >> > > > Apache
> > > >> > > > > > > > > > > Confluence (
> > > >> > > > > > > > > > > https://cwiki.apache.org) might be an
> acceptable
> > > >> > > > alternative.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > -----Original Message-----
> > > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > >> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> > > >> > > > > > > > > > > > Enable
> > > >> > Github
> > > >> > > > > > wiki in
> > > >> > > > > > > > > > > asf.yaml
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > I don't recall a discussion about this change,
> > > >> > > > > > > > > > > > but I
> > > >> > think
> > > >> > > > it
> > > >> > > > > > goes
> > > >> > > > > > > > > > > against previous efforts to make the website the
> > > >> > > > > > > > > > > one
> > > >> > > > canonical
> > > >> > > > > > > > > > > location for our documentation. I don't even
> > > >> > > > > > > > > > > think infra
> > > >> > is
> > > >> > > > > > backing
> > > >> > > > > > > > up
> > > >> > > > > > > > > > > wiki repos, so there wouldn't even be a record
> of
> > > >> > > > > > > > > > > the
> > > >> > wiki
> > > >> > > > > > contents
> > > >> > > > > > > > in
> > > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed
> up
> > > >> > > > > > > > > > > to
> > > >> > GitBox
> > > >> > > > and
> > > >> > > > > > the
> > > >> > > > > > > > > > > issue tracker, which CCs the notifications
> list).
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > In short, I think this should be reverted and
> > > >> > > > > > > > > > > > we
> > > >> > should not
> > > >> > > > > > use the
> > > >> > > > > > > > > > > GitHub wiki. If we need to store documents in a
> > > >> > > > > > > > > > > version
> > > >> > > > > > controlled
> > > >> > > > > > > > > > > way, we can store them on the website, or in our
> > > >> > project's
> > > >> > > > SVN
> > > >> > > > > > dev
> > > >> > > > > > > > > > > space. The wiki is just another place people
> > > >> > > > > > > > > > > would have
> > > >> > to
> > > >> > > > > > follow if
> > > >> > > > > > > > > > > they want to participate, and I don't think that
> > > >> > > > > > > > > > > serves
> > > >> > us.
> > > >> > > > > > > > Therefore,
> > > >> > > > > > > > > > > I think we shouldn't use it.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > > >> > > > > > > > > > > > <dl...@apache.org>
> > > >> > wrote:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > > This is an automated email from the ASF
> > > >> > > > > > > > > > > > > dual-hosted
> > > >> > git
> > > >> > > > > > > > repository.
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
> > > >> > > > > > > > > > > > > repository
> > > >> > > > > > > > > > > > >
> https://gitbox.apache.org/repos/asf/accumulo.
> > > >> > > > > > > > > > > > > git
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > The following commit(s) were added to
> > > >> > refs/heads/main by
> > > >> > > > this
> > > >> > > > > > > > push:
> > > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> > > >> > > > > > > > > > > > > asf.yaml
> > > >> > > > > > ae8a817e7b is
> > > >> > > > > > > > > > > > > described below
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > commit
> > > >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > >> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > >> > > > > > > > > > > > > ---
> > > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > > >> > > > > > > > > > > > > deletion(-)
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > >> > > > > > bc2c943e82..08aa357082
> > > >> > > > > > > > > > > > > 100644
> > > >> > > > > > > > > > > > > --- a/.asf.yaml
> > > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > >> > > > > > > > > > > > > - big-data
> > > >> > > > > > > > > > > > > - hacktoberfest
> > > >> > > > > > > > > > > > > features:
> > > >> > > > > > > > > > > > > - wiki: false
> > > >> > > > > > > > > > > > > + wiki: true
> > > >> > > > > > > > > > > > > issues: true
> > > >> > > > > > > > > > > > > projects: true
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > >
> > > >> > > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
I don't think the workflow I proposed about using PRs and discussion on
tickets, etc. and the accompanying arguments about keeping things
consolidated and accessible to potential contributors not participating on
GitHub, were really challenged at all. However, since I seem to be the only
one advocating for using the website, to keep things centralized, as per
previous attempts to consolidate documentation, I won't fight the use of
GitHub wiki. But I do want to make it clear that we're proceeding in that
direction under my objection (-0), and that I'm not convinced this is the
best path forward. Hopefully, I will be proven wrong in time.
On Wed, Mar 15, 2023, 11:58 Dave Marion <dm...@gmail.com> wrote:
> > At this point, I think we should move forward with a GH wiki and then we
> can re-evaluate things once the Apache confluence issue is sorted out.
>
> Agreed.
>
> On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
>
> > I just tried (Wed, 3/15) and still received the same error. I asked on
> > the infra slack channel and they replied that they are still working to
> > determine what the issue is - signs are pointing to something inside of
> > confluence, but no progress.
> >
> > At this point, I think we should move forward with a GH wiki and then we
> > can re-evaluate things once the Apache confluence issue is sorted out.
> >
> > Ed Coleman
> >
> > -----Original Message-----
> > From: Dave Marion <dm...@gmail.com>
> > Sent: Wednesday, March 8, 2023 11:09 AM
> > To: dev@accumulo.apache.org
> > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> >
> > Looking at the Infra slack channel response, one of the responses in the
> > channel said that "it's some sort of db corruption according to
> Atlassian".
> > Doesn't sound good....
> >
> > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com> wrote:
> >
> > > https://issues.apache.org/jira/browse/INFRA-24291 is still unresolved
> > > and the only comment on the ticket is one that Ed added two days ago
> > > requesting an ACCUMULO wiki space.
> > >
> > > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> > >
> > >> I do not see any comments in the infa slack channel - so no updates
> > >> for now.
> > >>
> > >> -----Original Message-----
> > >> From: Dave Marion <dm...@gmail.com>
> > >> Sent: Friday, March 3, 2023 12:06 PM
> > >> To: dev@accumulo.apache.org
> > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > >>
> > >> Right, I was just curious if there was any follow-up as I think Ed
> > >> said that it was going to be discussed by the INFRA team yesterday.
> > >> There is at least one other recent ticket (
> > >> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve
> > >> had an issue and the INFRA team created the space manually.
> > >>
> > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org>
> > wrote:
> > >>
> > >> > You can track that issue at
> > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > >> >
> > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > Ed,
> > >> > >
> > >> > > Any update from INFRA on being able to create confluence pages?
> > >> > >
> > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org>
> > >> wrote:
> > >> > >
> > >> > > > We've definitely used the website for more than that. We use it
> > >> > > > to document things for users, help developers know how to
> > >> > > > contribute, store drafts of designs, share user stories via
> > >> > > > blogs, do release announcements, and more. There's definitely
> > >> > > > space on the website to do this kind of thing, if we want to.
> > >> > > > We've used it that way before. If you only see it as a place
> > >> > > > "for user consumption after everything has been finalized",
> > >> > > > then you're missing out on the other ways we currently use the
> > >> > > > site, and the ways we've used it in
> > >> the past.
> > >> > > >
> > >> > > > With the website, most of the collaboration would happen in the
> > >> > > > GH issues about proposed designs or changes to designs, just
> > >> > > > like we do today with code or other documentation, which
> > >> > > > everybody is used to. I agree it's not as good as Google Docs
> > >> > > > for on-the-fly comments/annotations, but I don't think
> > >> > > > Confluence or Wiki are as good as that either, and Google Docs
> > isn't really an option...
> > >> > > > unless you just want to link to it in the mailing list and
> > >> > > > stick to Google Docs from your personal Google account, until
> > >> > > > it's ready for publication, which would also be fine (any
> > >> > > > interested persons can simply request write access by replying
> > >> > > > to the message where
> > >> you shared the link)..
> > >> > > >
> > >> > > > We are a much smaller project than many others, and we have
> > >> > > > previously suffered from having stuff too spread out. Even if
> > >> > > > other projects find a separate space valuable for them, I'm not
> > >> > > > sure it's best for the Accumulo project. While I think it's
> > >> > > > useful to examine what other projects do, I do think we should
> > >> > > > be careful to adopt anything just because others find it
> > convenient for them.
> > >> > > >
> > >> > > > Confluence is my second choice, but with a big gap between it
> > >> > > > and my first choice.
> > >> > > >
> > >> > > > On a personal note: I hate using Confluence, because I think
> > >> > > > the navigation is highly unintuitive, as is the permissions
> > >> > > > model, and I don't like the idea of learning yet another
> > >> > > > wiki-syntax (though I've read Confluence supports some limited
> > >> > > > Markdown, but probably not the same as GitHub/Jekyll). I also
> > >> > > > do not want to set up custom notifications for watching yet
> > >> > > > another space. If we use Confluence, I will probably contribute
> > >> > > > very infrequently there because of my frustrations with having
> > >> > > > used it before. However, that would be my choice, and should
> > >> > > > not be a reason the project chooses one over another. I'm
> > >> > > > sharing my personal opinion only because it is influencing my
> > >> > > > opinion about the website being more accessible, via our
> > >> > > > current GitHub PR/issue/Markdown workflows, and I wonder how
> > >> > > > many other potential contributors would feel similarly. It's
> > >> > > > hard to know, since it seems like a lot of this is subjective,
> > >> > > > and is going to come down to a consensus of personal
> > >> preferences.
> > >> > > >
> > >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> > >> > > > <dm...@gmail.com>
> > >> > wrote:
> > >> > > > >
> > >> > > > > I don't see the website as an area where we would have
> > >> > > > > collaborative discussions about an idea. For example, making
> > >> > > > > comments and
> > >> > suggestions
> > >> > > > on
> > >> > > > > a document like you can do in Google Docs. I see the website
> > >> > > > > as a
> > >> > place
> > >> > > > > where items are documented for user consumption after
> > >> > > > > everything has
> > >> > been
> > >> > > > > finalized. I'm not trying to create a private discussion
> > >> > > > > area, I
> > >> > think
> > >> > > > > anyone can see the wiki (but I think anonymous comments are
> > >> > > > > disabled
> > >> > due
> > >> > > > to
> > >> > > > > spam issues). I see no issue with putting work-in-progress
> > >> > > > > documents
> > >> > on a
> > >> > > > > wiki and referencing them via emails to the dev list. I think
> > >> > > > > this is
> > >> > > > done
> > >> > > > > in a lot of other projects. Non-committers that don't have
> > >> > > > > access to
> > >> > the
> > >> > > > > wiki and want to make comments, suggestions, and ask
> > >> > > > > questions can
> > >> > do so
> > >> > > > > via the mailing list. I think it's also possible that people
> > >> > > > > can get confluence accounts (see
> > >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > >> > > > > so if a non-committer wanted to participate they could.
> > >> > > > >
> > >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> > >> > > > > <ct...@apache.org>
> > >> > wrote:
> > >> > > > >
> > >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > >> > > > > > <dm...@gmail.com>
> > >> > > > wrote:
> > >> > > > > > >
> > >> > > > > > > I'm opposed to using the website for the reasons I
> > >> > > > > > > specified
> > >> > > > earlier, so
> > >> > > > > > it
> > >> > > > > >
> > >> > > > > > Your reasons that I saw were:
> > >> > > > > >
> > >> > > > > > > 1. I don't think internal design discussions should go on
> > >> > > > > > > the
> > >> > project
> > >> > > > > > website.
> > >> > > > > >
> > >> > > > > > That doesn't look to me like a reason. That appears to just
> > >> > > > > > be
> > >> > stating
> > >> > > > > > the conclusion. Did I miss your reason here?
> > >> > > > > >
> > >> > > > > > > 2. Changes to the design documents could not be seen by
> > >> > > > > > > others
> > >> > right
> > >> > > > > > away (IIRC changes to the website are built and available
> > >> > > > > > at https://accumulo.staged.apache.org/, but human
> > >> > > > > > intervention is
> > >> > > > required
> > >> > > > > > to publish it at https://accumulo.apache.org/).
> > >> > > > > >
> > >> > > > > > What do you mean by "others" here? Do you mean "users", as
> > >> > > > > > opposed
> > >> > to
> > >> > > > > > "developers/contributors"? The ASF draws a distinction
> > >> > > > > > between "developers/contributors" and "users" as it
> > >> > > > > > pertains to official releases. Releases are intended to be
> > >> > > > > > consumed by users, and pre-release stuff is intended to be
> > >> > > > > > collaborative, open to all potential
> > >> > > > > > developers/contributors. Very very rarely are things
> > >> > > > > > reserved exclusively for committers. We don't even have a
> > >> > > > > > private committers space (the private mailing list is
> > >> > > > > > PMC-private, not committer-private). Having a distinction
> > >> > > > > > between users and
> > >> > developers
> > >> > > > > > doesn't mean we can't publish things on the website... it
> > >> > > > > > just
> > >> > means
> > >> > > > > > that we should be careful about how we do it, which is the
> > >> > > > > > same
> > >> > care
> > >> > > > > > we should take regardless of where we put it. Specifically,
> > >> > > > > > the
> > >> > care
> > >> > > > > > we need to take is to avoid marketing pre-release content
> > >> > > > > > to
> > >> users.
> > >> > > > > > One way we can exercise this care for content on our
> > >> > > > > > website is
> > >> > that
> > >> > > > > > we can avoid sharing these unpolished designs by simply not
> > >> > > > > > linking them on the site, or by placing them in an area
> > >> > > > > > that is clearly
> > >> > marked
> > >> > > > > > as intended for devs. But, we have no similar distinction
> > >> > > > > > between committers and non-committer devs for which we
> > >> > > > > > should avoid sharing pre-release content under development.
> > >> > > > > > In fact, it is the
> > >> > opposite...
> > >> > > > > > we should be developing openly so as to allow room for
> > >> > non-committers
> > >> > > > > > to become committers through participation in development
> > >> > activities.
> > >> > > > > >
> > >> > > > > > As for the staging/publication of the website, that's just
> > >> > > > > > a
> > >> > mechanic
> > >> > > > > > for verifying the website isn't broken before we serve it.
> > >> > > > > > It's
> > >> > not a
> > >> > > > > > mechanism for keeping things internal vs. shared and
> > >> > > > > > doesn't have anything to do with the separation between
> > >> > > > > > devs and users. We
> > >> > already
> > >> > > > > > publish Draft contents to the website, as well as
> > >> > developer-specific
> > >> > > > > > documentation not intended for users.
> > >> > > > > >
> > >> > > > > > We've even specifically published work-in-progress design
> > >> > > > > > documents there, of the same type that seems to be the
> > >> > > > > > basis of this conversation (
> > >> https://accumulo.apache.org/design/system-snapshot).
> > >> > I
> > >> > > > > > would strongly prefer us to continue to do it this way,
> > >> > > > > > rather than create a new space, and have these kinds of
> > >> > > > > > things scattered in multiple places.
> > >> > > > > >
> > >> > > > > > If, on the other hand, you intend to say that these should
> > >> > > > > > be
> > >> > private
> > >> > > > > > because they aren't ready for other potential contributors,
> > >> > > > > > then I would argue that we're an openly developed project...
> > >> > > > > > if something isn't ready to be shared with other potential
> > >> > > > > > contributors / developers, such that you want to keep it
> > >> > > > > > internal to existing committers, then it's not ready to be
> > >> > > > > > contributed to the project at all... because we don't
> > >> > > > > > restrict collaboration to only existing committers. That
> > >> > > > > > would prevent others from participating and
> > >> > earning
> > >> > > > > > the merit to become committers, and that's not something we
> > >> > > > > > should
> > >> > be
> > >> > > > > > doing. Anything that is okay to share with existing
> > >> > > > > > committers
> > >> > should
> > >> > > > > > be okay to share to other potential contributors who want
> > >> > > > > > to participate, and should be done in a space that allows
> > >> > > > > > them to do that. The website is a perfect space for that,
> > >> > > > > > and has everything
> > >> > we
> > >> > > > > > need. I'm actually not sure about Confluence... I suspect
> > >> > > > > > non-committers wouldn't be able to participate there
> > >> > > > > > because they probably can't get accounts for it.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > > looks like we need to
> > >> > > > > > > wait for INFRA to fix Confluence. I'd be curious how much
> > >> > > > > > > we
> > >> > need to
> > >> > > > use
> > >> > > > > > > the mailing list during
> > >> > > > > > > the design phase. We can announce meeting dates/times on
> > >> > > > > > > the
> > >> > mailing
> > >> > > > list
> > >> > > > > > > and post links to
> > >> > > > > > > meeting notes in Confluence. Ultimately, decisions made
> > >> > > > > > > by the
> > >> > people
> > >> > > > > > that
> > >> > > > > > > want to be involved
> > >> > > > > > > will turn into pull requests against the codebase which
> > >> > comitters can
> > >> > > > > > weigh
> > >> > > > > > > in on. When you say,
> > >> > > > > > > "... but decisions about those would still need to be
> > >> > > > > > > done on the
> > >> > > > mailing
> > >> > > > > > > list." Are you saying that we need to discuss every
> > >> > > > > > > single design decision on the mailing
> > >> > list?
> > >> > > > > >
> > >> > > > > > Yes and no. I am saying that decisions need to happen on
> > >> > > > > > the
> > >> > mailing
> > >> > > > > > list, but I agree with you that this can be satisfied
> > >> > > > > > through pull requests. I just wanted to emphasize that
> > >> > > > > > regardless of where we do that pre-decision collaboration,
> > >> > > > > > that collaboration should not be misconstrued as a decision
> > >> > > > > > to
> > >> accept those ideas into the project.
> > >> > The
> > >> > > > > > decision occurs during the PR or other activity that
> > >> > > > > > interfaces
> > >> > with
> > >> > > > > > the mailing list, subsequent to the collaboration in the
> > >> > design/idea
> > >> > > > > > phase.
> > >> > > > > >
> > >> > > > > > As for the pre-decision collaboration space we're
> > >> > > > > > discussing, I
> > >> > just
> > >> > > > > > want to be careful that we're not creating such a space in
> > >> > > > > > an exclusionary way that allows only existing committers to
> > >> > participate,
> > >> > > > > > that excludes other potential contributors. This is still
> > >> > > > > > an openly-developed project, and we should collaborate in a
> > >> > > > > > space
> > >> > that is
> > >> > > > > > not exclusive to existing committers, but open to
> > >> > > > > > non-committer contributors and potential contributors as
> well.
> > >> > > > > > So, while we may
> > >> > want
> > >> > > > > > to keep a line separating dev activity from user
> > >> > > > > > consumption (an important separation that relates to
> > >> > > > > > official ASF releases), we
> > >> > should
> > >> > > > > > not be drawing a line between committer-devs as "internal"
> > >> > > > > > and contributor-devs as "external". The website, with its
> > >> > > > > > own issue tracker, the ability to render markdown, do
> > >> > > > > > reviews, and collaboratively edit, seems like the ideal
> > >> > > > > > place to me. We've used
> > >> > it
> > >> > > > > > before for the same purpose, and I think we should continue
> > >> > > > > > to do
> > >> > so.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > >> > > > > > > <ctubbsii@apache.org
> > >> > >
> > >> > > > wrote:
> > >> > > > > > >
> > >> > > > > > > > So, I agree a space would be helpful. Although it's old
> > >> > > > > > > > school
> > >> > and
> > >> > > > > > > > inconvenient, the mailing list is the canonical place
> > >> > > > > > > > for
> > >> > > > discussion.
> > >> > > > > > > > We currently use GitHub issues a lot, but that's copied
> > >> > > > > > > > to a
> > >> > > > mailing
> > >> > > > > > > > list (as is our old JIRA space), so if people want to
> > >> > participate
> > >> > > > > > > > without a GitHub account, they can still do that. There
> > >> > > > > > > > are
> > >> > certain
> > >> > > > > > > > options that are perhaps less convenient, such as just
> > >> > > > > > > > using
> > >> > the
> > >> > > > > > > > mailing list and our dev SVN space, but still more
> > >> > > > > > > > appropriate
> > >> > than
> > >> > > > > > > > options that would be less ubiquitous for potential
> > >> > participants.
> > >> > > > > > > >
> > >> > > > > > > > I think the ASF Confluence is probably fine, for
> > >> > > > > > > > storing,
> > >> > editing,
> > >> > > > and
> > >> > > > > > > > collaborating on shared documents, but decisions about
> > >> > > > > > > > those
> > >> > would
> > >> > > > > > > > still need to be done on the mailing list. If I
> > >> > > > > > > > remember
> > >> > > > correctly, we
> > >> > > > > > > > used to have a Wiki space, prior to it being
> > >> > > > > > > > transferred to Confluence, but it was poorly
> > >> > > > > > > > maintained, so we abandoned it in
> > >> > > > favor
> > >> > > > > > > > of using the website for docs. I could be
> > >> > > > > > > > mis-remembering, but
> > >> > I
> > >> > > > think
> > >> > > > > > > > this is the case. It might explain why you can't create
> > >> > > > > > > > a
> > >> > > > Confluence
> > >> > > > > > > > space.
> > >> > > > > > > >
> > >> > > > > > > > My preference would be to just use the website. I think
> > >> > > > > > > > it's
> > >> > fine
> > >> > > > to
> > >> > > > > > > > have a dev / design area of the website, and we can
> > >> > > > > > > > discuss on
> > >> > > > GitHub
> > >> > > > > > > > issues for the accumulo-website repo. That is a bit
> > >> > > > > > > > less
> > >> > convenient
> > >> > > > > > > > than Confluence if it's used heavily, but it's more
> > >> > > > > > > > convenient
> > >> > in
> > >> > > > the
> > >> > > > > > > > sense that it's more accessible and fits more in line
> > >> > > > > > > > with our
> > >> > > > current
> > >> > > > > > > > mode of operation. Plus, when a document is final, it's
> > >> > > > > > > > easy to
> > >> > > > link
> > >> > > > > > > > to from our documentation, without making users jump to
> > >> > > > > > > > another service to view docs.
> > >> > > > > > > >
> > >> > > > > > > > I would be opposed to using GitHub wiki or a new git
> repo.
> > >> > > > > > > > We
> > >> > have
> > >> > > > > > > > enough repos. Although it seems like they are free,
> > >> > > > > > > > there is
> > >> > still
> > >> > > > a
> > >> > > > > > > > lot of boilerplate work to maintain them, from managing
> > >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> > >> > .asf.yaml, to
> > >> > > > > > > > README, to keeping copyright dates updated in the
> > >> > > > > > > > NOTICE file,
> > >> > and
> > >> > > > > > > > more.
> > >> > > > > > > >
> > >> > > > > > > > In summary, my preference:
> > >> > > > > > > >
> > >> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
> > >> > > > > > > > issues and
> > >> > > > mailing
> > >> > > > > > > > list (strongly preferred) 2. Confluence, discuss on
> > >> > > > > > > > mailing list (prefer over other
> > >> > options,
> > >> > > > but
> > >> > > > > > > > not a fan)
> > >> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
> > >> > > > > > > > prefer not
> > >> > to use
> > >> > > > > > this
> > >> > > > > > > > option)
> > >> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing
> > >> > > > > > > > list
> > >> > (strongly
> > >> > > > > > > > prefer not to use this option)
> > >> > > > > > > >
> > >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > >> > edcoleman@apache.org>
> > >> > > > > > wrote:
> > >> > > > > > > > >
> > >> > > > > > > > > Currently, asf cannot create new wiki's because of a
> > >> > Confluence
> > >> > > > > > issue (
> > >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
> > >> > > > > > > > chatted
> > >> > with
> > >> > > > > > infra
> > >> > > > > > > > and in response they created that issue.
> > >> > > > > > > > >
> > >> > > > > > > > > To expand on this discussion, I would like to toss
> > >> > > > > > > > > out
> > >> > another
> > >> > > > > > > > alternative to discuss / explore. What if we used a
> > >> > > > > > > > separate
> > >> > > > GitHub
> > >> > > > > > > > project, something like Accumulo-Design, just like
> > >> > accumulo-proxy
> > >> > > > and
> > >> > > > > > > > accumulo-examples. As a separate project, it would be
> > >> > available
> > >> > > > for
> > >> > > > > > > > collaboration for the community, but remain separate
> > >> > > > > > > > from main
> > >> > > > project
> > >> > > > > > and
> > >> > > > > > > > the website to keep current code / documentation /
> > >> > > > > > > > design
> > >> > clearly
> > >> > > > > > separate
> > >> > > > > > > > from speculative design discussions. As a project:
> > >> > > > > > > > >
> > >> > > > > > > > > - document history would be preserved with git commit
> > >> > history.
> > >> > > > > > > > > - document collaboration could be done with normal PR
> > >> > > > submissions /
> > >> > > > > > > > reviews.
> > >> > > > > > > > > - issues could be used to discuss design aspects,
> > >> > > > > > > > > capturing
> > >> > the
> > >> > > > > > comment
> > >> > > > > > > > history.
> > >> > > > > > > > >
> > >> > > > > > > > > The biggest downside is that it would be yet another
> > >> > > > > > > > > project
> > >> > to
> > >> > > > > > follow /
> > >> > > > > > > > track.
> > >> > > > > > > > >
> > >> > > > > > > > > For me, I think the issue is that we need a public,
> > >> > collaborative
> > >> > > > > > space
> > >> > > > > > > > to hold design discussions. Neither the main project or
> > >> > > > > > > > the
> > >> > > > web-site
> > >> > > > > > seem
> > >> > > > > > > > quite appropriate and Confluence seems to lack the
> > >> > collaboration
> > >> > > > that
> > >> > > > > > can
> > >> > > > > > > > be achieved with github.
> > >> > > > > > > > >
> > >> > > > > > > > > We need a space to capture the redesign and whatever
> > >> > > > > > > > > we
> > >> > select
> > >> > > > can be
> > >> > > > > > > > made to work - I'm just wondering what provides the
> > >> > > > > > > > easiest
> > >> > forum
> > >> > > > to
> > >> > > > > > build
> > >> > > > > > > > a collaborative space for the Accumulo community.
> > >> > > > > > > > >
> > >> > > > > > > > > Ed Coleman
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > >> > > > > > > > > > Circling back on this issue - I agree that comments
> > >> > > > > > > > > > and
> > >> > such
> > >> > > > make
> > >> > > > > > > > sense for internal design documents. I'm going to
> > >> > > > > > > > create an
> > >> > INFRA
> > >> > > > > > ticket
> > >> > > > > > > > for a cwiki space for Accumulo unless there are any
> > >> objections.
> > >> > > > > > > > > >
> > >> > > > > > > > > > -----Original Message-----
> > >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > >> > > > > > > > > > To: dev@accumulo.apache.org
> > >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in
> asf.yaml?
> > >> > > > > > > > > >
> > >> > > > > > > > > > As mentioned, wikis can provide a streamlined
> > >> > > > > > > > > > collaborative
> > >> > > > editing
> > >> > > > > > > > workflow that's less labor intensive than updating a
> > >> website.
> > >> > They
> > >> > > > can
> > >> > > > > > > > promote collaboration by providing specific tooling to
> > >> > > > > > > > support
> > >> > > > > > comments,
> > >> > > > > > > > revisions and iteration.
> > >> > > > > > > > > >
> > >> > > > > > > > > > In terms of preservation, GH wikis act just like
> > >> > > > > > > > > > any other
> > >> > Git
> > >> > > > > > > > repository, with a remote at (for example)
> git@github.com
> > :
> > >> > > > > > > > apache/accumulo.wiki.git
> > >> > > > > > > > > > IIRC the pages are just GH flavored markdown. There
> > >> > > > > > > > > > are at
> > >> > > > least a
> > >> > > > > > few
> > >> > > > > > > > Apache projects using them.
> > >> > > > > > > > > >
> > >> > > > > > > > > > However, GH wikis lack some features that I feel
> > >> > > > > > > > > > are
> > >> > important
> > >> > > > to
> > >> > > > > > > > support collaborative authoring. For example, the
> > >> > > > > > > > ability to
> > >> > > > comment
> > >> > > > > > and
> > >> > > > > > > > discuss specific passages in a document is a feature
> > >> > > > > > > > that's
> > >> > > > present in
> > >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate this
> > >> > > > > > > > this in
> > >> > my
> > >> > > > google
> > >> > > > > > > > docs and office workflows, so expect that it would be
> > >> > > > > > > > useful
> > >> > for
> > >> > > > > > Accumulo
> > >> > > > > > > > design discussions too.
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > >> > > > kturner@apache.org>
> > >> > > > > > > > wrote:
> > >> > > > > > > > > >
> > >> > > > > > > > > > > I would like to try a wiki for design documents,
> > >> > > > > > > > > > > I think
> > >> > it
> > >> > > > > > would be
> > >> > > > > > > > > > > less cumbersome than the website and we can
> > >> > > > > > > > > > > always link
> > >> > from
> > >> > > > the
> > >> > > > > > > > > > > website and issues to the wiki. I think its ok
> > >> > > > > > > > > > > to give
> > >> > it a
> > >> > > > try
> > >> > > > > > and
> > >> > > > > > > > > > > abandon it in the future, if abandoned would just
> > >> > > > > > > > > > > need to
> > >> > > > > > properly
> > >> > > > > > > > > > > communicate that. The content should be archived
> > >> > > > > > > > > > > in
> > >> > Apache
> > >> > > > > > > > > > > infrastructure, so if GH wiki does not do that
> > >> > > > > > > > > > > then we
> > >> > should
> > >> > > > > > not use
> > >> > > > > > > > > > > it. If GH wiki is not an option then could try
> > cwiki.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > >> > > > > > > > > > > <dl...@comcast.net>
> > >> > > > wrote:
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > I reverted the change. I didn't think it would
> > >> > > > > > > > > > > > be a big
> > >> > > > deal,
> > >> > > > > > but
> > >> > > > > > > > if
> > >> > > > > > > > > > > > it
> > >> > > > > > > > > > > requires discussion, then let's discuss it.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > I'm looking for a place to host information
> > >> > > > > > > > > > > > related to
> > >> > > > internal
> > >> > > > > > > > > > > > design
> > >> > > > > > > > > > > discussions. I envision these to be living
> > >> > > > > > > > > > > documents that
> > >> > > > will be
> > >> > > > > > > > > > > updated over time as the design/implementation
> > >> > progresses and
> > >> > > > > > that
> > >> > > > > > > > > > > other committers will be able to comment on and
> > >> > > > > > > > > > > edit. I
> > >> > don't
> > >> > > > > > feel
> > >> > > > > > > > > > > that the website is the correct place for this
> > >> because:
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > 1. I don't think internal design discussions
> > >> > > > > > > > > > > > should
> > >> > go
> > >> > > > on the
> > >> > > > > > > > > > > > project
> > >> > > > > > > > > > > website.
> > >> > > > > > > > > > > > 2. Changes to the design documents could not
> > >> > > > > > > > > > > > be seen
> > >> > by
> > >> > > > > > others
> > >> > > > > > > > > > > > right
> > >> > > > > > > > > > > away (IIRC changes to the website are built and
> > >> > available at
> > >> > > > > > > > > > > https://accumulo.staged.apache.org/, but human
> > >> > intervention
> > >> > > > is
> > >> > > > > > > > > > > required to publish it at
> > >> https://accumulo.apache.org/).
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > I looked in the INFRA issues and other projects
> > >> > > > > > > > > > > > are
> > >> > using
> > >> > > > the
> > >> > > > > > GH
> > >> > > > > > > > > > > > Wiki
> > >> > > > > > > > > > > feature and I saw no mention of backing it up or
> > >> > > > > > > > > > > the
> > >> > > > requirement
> > >> > > > > > to
> > >> > > > > > > > do
> > >> > > > > > > > > > > so (maybe they rely on GitHub backing it up?). It
> > >> > > > > > > > > > > does
> > >> > appear
> > >> > > > > > that we
> > >> > > > > > > > > > > would need an INFRA ticket so that they can
> > >> > > > > > > > > > > modify the
> > >> > GitHub
> > >> > > > > > project
> > >> > > > > > > > > > > settings to lock the GitHub wiki down so that
> > >> > > > > > > > > > > only
> > >> > > > committers can
> > >> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then
> > >> > > > > > > > > > > I think
> > >> > > > Apache
> > >> > > > > > > > > > > Confluence (
> > >> > > > > > > > > > > https://cwiki.apache.org) might be an acceptable
> > >> > > > alternative.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > -----Original Message-----
> > >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > >> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > >> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> > >> > > > > > > > > > > > Enable
> > >> > Github
> > >> > > > > > wiki in
> > >> > > > > > > > > > > asf.yaml
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > I don't recall a discussion about this change,
> > >> > > > > > > > > > > > but I
> > >> > think
> > >> > > > it
> > >> > > > > > goes
> > >> > > > > > > > > > > against previous efforts to make the website the
> > >> > > > > > > > > > > one
> > >> > > > canonical
> > >> > > > > > > > > > > location for our documentation. I don't even
> > >> > > > > > > > > > > think infra
> > >> > is
> > >> > > > > > backing
> > >> > > > > > > > up
> > >> > > > > > > > > > > wiki repos, so there wouldn't even be a record of
> > >> > > > > > > > > > > the
> > >> > wiki
> > >> > > > > > contents
> > >> > > > > > > > in
> > >> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed up
> > >> > > > > > > > > > > to
> > >> > GitBox
> > >> > > > and
> > >> > > > > > the
> > >> > > > > > > > > > > issue tracker, which CCs the notifications list).
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > In short, I think this should be reverted and
> > >> > > > > > > > > > > > we
> > >> > should not
> > >> > > > > > use the
> > >> > > > > > > > > > > GitHub wiki. If we need to store documents in a
> > >> > > > > > > > > > > version
> > >> > > > > > controlled
> > >> > > > > > > > > > > way, we can store them on the website, or in our
> > >> > project's
> > >> > > > SVN
> > >> > > > > > dev
> > >> > > > > > > > > > > space. The wiki is just another place people
> > >> > > > > > > > > > > would have
> > >> > to
> > >> > > > > > follow if
> > >> > > > > > > > > > > they want to participate, and I don't think that
> > >> > > > > > > > > > > serves
> > >> > us.
> > >> > > > > > > > Therefore,
> > >> > > > > > > > > > > I think we shouldn't use it.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> > >> > > > > > > > > > > > <dl...@apache.org>
> > >> > wrote:
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > > This is an automated email from the ASF
> > >> > > > > > > > > > > > > dual-hosted
> > >> > git
> > >> > > > > > > > repository.
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
> > >> > > > > > > > > > > > > repository
> > >> > > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.
> > >> > > > > > > > > > > > > git
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > The following commit(s) were added to
> > >> > refs/heads/main by
> > >> > > > this
> > >> > > > > > > > push:
> > >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> > >> > > > > > > > > > > > > asf.yaml
> > >> > > > > > ae8a817e7b is
> > >> > > > > > > > > > > > > described below
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > commit
> > >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > >> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > >> > > > > > > > > > > > > ---
> > >> > > > > > > > > > > > > .asf.yaml | 2 +-
> > >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> > >> > > > > > > > > > > > > deletion(-)
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > >> > > > > > bc2c943e82..08aa357082
> > >> > > > > > > > > > > > > 100644
> > >> > > > > > > > > > > > > --- a/.asf.yaml
> > >> > > > > > > > > > > > > +++ b/.asf.yaml
> > >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > >> > > > > > > > > > > > > - big-data
> > >> > > > > > > > > > > > > - hacktoberfest
> > >> > > > > > > > > > > > > features:
> > >> > > > > > > > > > > > > - wiki: false
> > >> > > > > > > > > > > > > + wiki: true
> > >> > > > > > > > > > > > > issues: true
> > >> > > > > > > > > > > > > projects: true
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > >
> > >> > > > > >
> > >> > > >
> > >> >
> > >>
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
> At this point, I think we should move forward with a GH wiki and then we
can re-evaluate things once the Apache confluence issue is sorted out.
Agreed.
On Wed, Mar 15, 2023 at 11:57 AM dev1 <de...@etcoleman.com> wrote:
> I just tried (Wed, 3/15) and still received the same error. I asked on
> the infra slack channel and they replied that they are still working to
> determine what the issue is - signs are pointing to something inside of
> confluence, but no progress.
>
> At this point, I think we should move forward with a GH wiki and then we
> can re-evaluate things once the Apache confluence issue is sorted out.
>
> Ed Coleman
>
> -----Original Message-----
> From: Dave Marion <dm...@gmail.com>
> Sent: Wednesday, March 8, 2023 11:09 AM
> To: dev@accumulo.apache.org
> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>
> Looking at the Infra slack channel response, one of the responses in the
> channel said that "it's some sort of db corruption according to Atlassian".
> Doesn't sound good....
>
> On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com> wrote:
>
> > https://issues.apache.org/jira/browse/INFRA-24291 is still unresolved
> > and the only comment on the ticket is one that Ed added two days ago
> > requesting an ACCUMULO wiki space.
> >
> > On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> >
> >> I do not see any comments in the infa slack channel - so no updates
> >> for now.
> >>
> >> -----Original Message-----
> >> From: Dave Marion <dm...@gmail.com>
> >> Sent: Friday, March 3, 2023 12:06 PM
> >> To: dev@accumulo.apache.org
> >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> >>
> >> Right, I was just curious if there was any follow-up as I think Ed
> >> said that it was going to be discussed by the INFRA team yesterday.
> >> There is at least one other recent ticket (
> >> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve
> >> had an issue and the INFRA team created the space manually.
> >>
> >> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org>
> wrote:
> >>
> >> > You can track that issue at
> >> > https://issues.apache.org/jira/browse/INFRA-24291
> >> >
> >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com>
> >> wrote:
> >> > >
> >> > > Ed,
> >> > >
> >> > > Any update from INFRA on being able to create confluence pages?
> >> > >
> >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org>
> >> wrote:
> >> > >
> >> > > > We've definitely used the website for more than that. We use it
> >> > > > to document things for users, help developers know how to
> >> > > > contribute, store drafts of designs, share user stories via
> >> > > > blogs, do release announcements, and more. There's definitely
> >> > > > space on the website to do this kind of thing, if we want to.
> >> > > > We've used it that way before. If you only see it as a place
> >> > > > "for user consumption after everything has been finalized",
> >> > > > then you're missing out on the other ways we currently use the
> >> > > > site, and the ways we've used it in
> >> the past.
> >> > > >
> >> > > > With the website, most of the collaboration would happen in the
> >> > > > GH issues about proposed designs or changes to designs, just
> >> > > > like we do today with code or other documentation, which
> >> > > > everybody is used to. I agree it's not as good as Google Docs
> >> > > > for on-the-fly comments/annotations, but I don't think
> >> > > > Confluence or Wiki are as good as that either, and Google Docs
> isn't really an option...
> >> > > > unless you just want to link to it in the mailing list and
> >> > > > stick to Google Docs from your personal Google account, until
> >> > > > it's ready for publication, which would also be fine (any
> >> > > > interested persons can simply request write access by replying
> >> > > > to the message where
> >> you shared the link)..
> >> > > >
> >> > > > We are a much smaller project than many others, and we have
> >> > > > previously suffered from having stuff too spread out. Even if
> >> > > > other projects find a separate space valuable for them, I'm not
> >> > > > sure it's best for the Accumulo project. While I think it's
> >> > > > useful to examine what other projects do, I do think we should
> >> > > > be careful to adopt anything just because others find it
> convenient for them.
> >> > > >
> >> > > > Confluence is my second choice, but with a big gap between it
> >> > > > and my first choice.
> >> > > >
> >> > > > On a personal note: I hate using Confluence, because I think
> >> > > > the navigation is highly unintuitive, as is the permissions
> >> > > > model, and I don't like the idea of learning yet another
> >> > > > wiki-syntax (though I've read Confluence supports some limited
> >> > > > Markdown, but probably not the same as GitHub/Jekyll). I also
> >> > > > do not want to set up custom notifications for watching yet
> >> > > > another space. If we use Confluence, I will probably contribute
> >> > > > very infrequently there because of my frustrations with having
> >> > > > used it before. However, that would be my choice, and should
> >> > > > not be a reason the project chooses one over another. I'm
> >> > > > sharing my personal opinion only because it is influencing my
> >> > > > opinion about the website being more accessible, via our
> >> > > > current GitHub PR/issue/Markdown workflows, and I wonder how
> >> > > > many other potential contributors would feel similarly. It's
> >> > > > hard to know, since it seems like a lot of this is subjective,
> >> > > > and is going to come down to a consensus of personal
> >> preferences.
> >> > > >
> >> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
> >> > > > <dm...@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > I don't see the website as an area where we would have
> >> > > > > collaborative discussions about an idea. For example, making
> >> > > > > comments and
> >> > suggestions
> >> > > > on
> >> > > > > a document like you can do in Google Docs. I see the website
> >> > > > > as a
> >> > place
> >> > > > > where items are documented for user consumption after
> >> > > > > everything has
> >> > been
> >> > > > > finalized. I'm not trying to create a private discussion
> >> > > > > area, I
> >> > think
> >> > > > > anyone can see the wiki (but I think anonymous comments are
> >> > > > > disabled
> >> > due
> >> > > > to
> >> > > > > spam issues). I see no issue with putting work-in-progress
> >> > > > > documents
> >> > on a
> >> > > > > wiki and referencing them via emails to the dev list. I think
> >> > > > > this is
> >> > > > done
> >> > > > > in a lot of other projects. Non-committers that don't have
> >> > > > > access to
> >> > the
> >> > > > > wiki and want to make comments, suggestions, and ask
> >> > > > > questions can
> >> > do so
> >> > > > > via the mailing list. I think it's also possible that people
> >> > > > > can get confluence accounts (see
> >> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> >> > > > > so if a non-committer wanted to participate they could.
> >> > > > >
> >> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
> >> > > > > <ct...@apache.org>
> >> > wrote:
> >> > > > >
> >> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> >> > > > > > <dm...@gmail.com>
> >> > > > wrote:
> >> > > > > > >
> >> > > > > > > I'm opposed to using the website for the reasons I
> >> > > > > > > specified
> >> > > > earlier, so
> >> > > > > > it
> >> > > > > >
> >> > > > > > Your reasons that I saw were:
> >> > > > > >
> >> > > > > > > 1. I don't think internal design discussions should go on
> >> > > > > > > the
> >> > project
> >> > > > > > website.
> >> > > > > >
> >> > > > > > That doesn't look to me like a reason. That appears to just
> >> > > > > > be
> >> > stating
> >> > > > > > the conclusion. Did I miss your reason here?
> >> > > > > >
> >> > > > > > > 2. Changes to the design documents could not be seen by
> >> > > > > > > others
> >> > right
> >> > > > > > away (IIRC changes to the website are built and available
> >> > > > > > at https://accumulo.staged.apache.org/, but human
> >> > > > > > intervention is
> >> > > > required
> >> > > > > > to publish it at https://accumulo.apache.org/).
> >> > > > > >
> >> > > > > > What do you mean by "others" here? Do you mean "users", as
> >> > > > > > opposed
> >> > to
> >> > > > > > "developers/contributors"? The ASF draws a distinction
> >> > > > > > between "developers/contributors" and "users" as it
> >> > > > > > pertains to official releases. Releases are intended to be
> >> > > > > > consumed by users, and pre-release stuff is intended to be
> >> > > > > > collaborative, open to all potential
> >> > > > > > developers/contributors. Very very rarely are things
> >> > > > > > reserved exclusively for committers. We don't even have a
> >> > > > > > private committers space (the private mailing list is
> >> > > > > > PMC-private, not committer-private). Having a distinction
> >> > > > > > between users and
> >> > developers
> >> > > > > > doesn't mean we can't publish things on the website... it
> >> > > > > > just
> >> > means
> >> > > > > > that we should be careful about how we do it, which is the
> >> > > > > > same
> >> > care
> >> > > > > > we should take regardless of where we put it. Specifically,
> >> > > > > > the
> >> > care
> >> > > > > > we need to take is to avoid marketing pre-release content
> >> > > > > > to
> >> users.
> >> > > > > > One way we can exercise this care for content on our
> >> > > > > > website is
> >> > that
> >> > > > > > we can avoid sharing these unpolished designs by simply not
> >> > > > > > linking them on the site, or by placing them in an area
> >> > > > > > that is clearly
> >> > marked
> >> > > > > > as intended for devs. But, we have no similar distinction
> >> > > > > > between committers and non-committer devs for which we
> >> > > > > > should avoid sharing pre-release content under development.
> >> > > > > > In fact, it is the
> >> > opposite...
> >> > > > > > we should be developing openly so as to allow room for
> >> > non-committers
> >> > > > > > to become committers through participation in development
> >> > activities.
> >> > > > > >
> >> > > > > > As for the staging/publication of the website, that's just
> >> > > > > > a
> >> > mechanic
> >> > > > > > for verifying the website isn't broken before we serve it.
> >> > > > > > It's
> >> > not a
> >> > > > > > mechanism for keeping things internal vs. shared and
> >> > > > > > doesn't have anything to do with the separation between
> >> > > > > > devs and users. We
> >> > already
> >> > > > > > publish Draft contents to the website, as well as
> >> > developer-specific
> >> > > > > > documentation not intended for users.
> >> > > > > >
> >> > > > > > We've even specifically published work-in-progress design
> >> > > > > > documents there, of the same type that seems to be the
> >> > > > > > basis of this conversation (
> >> https://accumulo.apache.org/design/system-snapshot).
> >> > I
> >> > > > > > would strongly prefer us to continue to do it this way,
> >> > > > > > rather than create a new space, and have these kinds of
> >> > > > > > things scattered in multiple places.
> >> > > > > >
> >> > > > > > If, on the other hand, you intend to say that these should
> >> > > > > > be
> >> > private
> >> > > > > > because they aren't ready for other potential contributors,
> >> > > > > > then I would argue that we're an openly developed project...
> >> > > > > > if something isn't ready to be shared with other potential
> >> > > > > > contributors / developers, such that you want to keep it
> >> > > > > > internal to existing committers, then it's not ready to be
> >> > > > > > contributed to the project at all... because we don't
> >> > > > > > restrict collaboration to only existing committers. That
> >> > > > > > would prevent others from participating and
> >> > earning
> >> > > > > > the merit to become committers, and that's not something we
> >> > > > > > should
> >> > be
> >> > > > > > doing. Anything that is okay to share with existing
> >> > > > > > committers
> >> > should
> >> > > > > > be okay to share to other potential contributors who want
> >> > > > > > to participate, and should be done in a space that allows
> >> > > > > > them to do that. The website is a perfect space for that,
> >> > > > > > and has everything
> >> > we
> >> > > > > > need. I'm actually not sure about Confluence... I suspect
> >> > > > > > non-committers wouldn't be able to participate there
> >> > > > > > because they probably can't get accounts for it.
> >> > > > > >
> >> > > > > >
> >> > > > > > > looks like we need to
> >> > > > > > > wait for INFRA to fix Confluence. I'd be curious how much
> >> > > > > > > we
> >> > need to
> >> > > > use
> >> > > > > > > the mailing list during
> >> > > > > > > the design phase. We can announce meeting dates/times on
> >> > > > > > > the
> >> > mailing
> >> > > > list
> >> > > > > > > and post links to
> >> > > > > > > meeting notes in Confluence. Ultimately, decisions made
> >> > > > > > > by the
> >> > people
> >> > > > > > that
> >> > > > > > > want to be involved
> >> > > > > > > will turn into pull requests against the codebase which
> >> > comitters can
> >> > > > > > weigh
> >> > > > > > > in on. When you say,
> >> > > > > > > "... but decisions about those would still need to be
> >> > > > > > > done on the
> >> > > > mailing
> >> > > > > > > list." Are you saying that we need to discuss every
> >> > > > > > > single design decision on the mailing
> >> > list?
> >> > > > > >
> >> > > > > > Yes and no. I am saying that decisions need to happen on
> >> > > > > > the
> >> > mailing
> >> > > > > > list, but I agree with you that this can be satisfied
> >> > > > > > through pull requests. I just wanted to emphasize that
> >> > > > > > regardless of where we do that pre-decision collaboration,
> >> > > > > > that collaboration should not be misconstrued as a decision
> >> > > > > > to
> >> accept those ideas into the project.
> >> > The
> >> > > > > > decision occurs during the PR or other activity that
> >> > > > > > interfaces
> >> > with
> >> > > > > > the mailing list, subsequent to the collaboration in the
> >> > design/idea
> >> > > > > > phase.
> >> > > > > >
> >> > > > > > As for the pre-decision collaboration space we're
> >> > > > > > discussing, I
> >> > just
> >> > > > > > want to be careful that we're not creating such a space in
> >> > > > > > an exclusionary way that allows only existing committers to
> >> > participate,
> >> > > > > > that excludes other potential contributors. This is still
> >> > > > > > an openly-developed project, and we should collaborate in a
> >> > > > > > space
> >> > that is
> >> > > > > > not exclusive to existing committers, but open to
> >> > > > > > non-committer contributors and potential contributors as well.
> >> > > > > > So, while we may
> >> > want
> >> > > > > > to keep a line separating dev activity from user
> >> > > > > > consumption (an important separation that relates to
> >> > > > > > official ASF releases), we
> >> > should
> >> > > > > > not be drawing a line between committer-devs as "internal"
> >> > > > > > and contributor-devs as "external". The website, with its
> >> > > > > > own issue tracker, the ability to render markdown, do
> >> > > > > > reviews, and collaboratively edit, seems like the ideal
> >> > > > > > place to me. We've used
> >> > it
> >> > > > > > before for the same purpose, and I think we should continue
> >> > > > > > to do
> >> > so.
> >> > > > > >
> >> > > > > >
> >> > > > > > >
> >> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> >> > > > > > > <ctubbsii@apache.org
> >> > >
> >> > > > wrote:
> >> > > > > > >
> >> > > > > > > > So, I agree a space would be helpful. Although it's old
> >> > > > > > > > school
> >> > and
> >> > > > > > > > inconvenient, the mailing list is the canonical place
> >> > > > > > > > for
> >> > > > discussion.
> >> > > > > > > > We currently use GitHub issues a lot, but that's copied
> >> > > > > > > > to a
> >> > > > mailing
> >> > > > > > > > list (as is our old JIRA space), so if people want to
> >> > participate
> >> > > > > > > > without a GitHub account, they can still do that. There
> >> > > > > > > > are
> >> > certain
> >> > > > > > > > options that are perhaps less convenient, such as just
> >> > > > > > > > using
> >> > the
> >> > > > > > > > mailing list and our dev SVN space, but still more
> >> > > > > > > > appropriate
> >> > than
> >> > > > > > > > options that would be less ubiquitous for potential
> >> > participants.
> >> > > > > > > >
> >> > > > > > > > I think the ASF Confluence is probably fine, for
> >> > > > > > > > storing,
> >> > editing,
> >> > > > and
> >> > > > > > > > collaborating on shared documents, but decisions about
> >> > > > > > > > those
> >> > would
> >> > > > > > > > still need to be done on the mailing list. If I
> >> > > > > > > > remember
> >> > > > correctly, we
> >> > > > > > > > used to have a Wiki space, prior to it being
> >> > > > > > > > transferred to Confluence, but it was poorly
> >> > > > > > > > maintained, so we abandoned it in
> >> > > > favor
> >> > > > > > > > of using the website for docs. I could be
> >> > > > > > > > mis-remembering, but
> >> > I
> >> > > > think
> >> > > > > > > > this is the case. It might explain why you can't create
> >> > > > > > > > a
> >> > > > Confluence
> >> > > > > > > > space.
> >> > > > > > > >
> >> > > > > > > > My preference would be to just use the website. I think
> >> > > > > > > > it's
> >> > fine
> >> > > > to
> >> > > > > > > > have a dev / design area of the website, and we can
> >> > > > > > > > discuss on
> >> > > > GitHub
> >> > > > > > > > issues for the accumulo-website repo. That is a bit
> >> > > > > > > > less
> >> > convenient
> >> > > > > > > > than Confluence if it's used heavily, but it's more
> >> > > > > > > > convenient
> >> > in
> >> > > > the
> >> > > > > > > > sense that it's more accessible and fits more in line
> >> > > > > > > > with our
> >> > > > current
> >> > > > > > > > mode of operation. Plus, when a document is final, it's
> >> > > > > > > > easy to
> >> > > > link
> >> > > > > > > > to from our documentation, without making users jump to
> >> > > > > > > > another service to view docs.
> >> > > > > > > >
> >> > > > > > > > I would be opposed to using GitHub wiki or a new git repo.
> >> > > > > > > > We
> >> > have
> >> > > > > > > > enough repos. Although it seems like they are free,
> >> > > > > > > > there is
> >> > still
> >> > > > a
> >> > > > > > > > lot of boilerplate work to maintain them, from managing
> >> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> >> > .asf.yaml, to
> >> > > > > > > > README, to keeping copyright dates updated in the
> >> > > > > > > > NOTICE file,
> >> > and
> >> > > > > > > > more.
> >> > > > > > > >
> >> > > > > > > > In summary, my preference:
> >> > > > > > > >
> >> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
> >> > > > > > > > issues and
> >> > > > mailing
> >> > > > > > > > list (strongly preferred) 2. Confluence, discuss on
> >> > > > > > > > mailing list (prefer over other
> >> > options,
> >> > > > but
> >> > > > > > > > not a fan)
> >> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
> >> > > > > > > > prefer not
> >> > to use
> >> > > > > > this
> >> > > > > > > > option)
> >> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing
> >> > > > > > > > list
> >> > (strongly
> >> > > > > > > > prefer not to use this option)
> >> > > > > > > >
> >> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> >> > edcoleman@apache.org>
> >> > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > Currently, asf cannot create new wiki's because of a
> >> > Confluence
> >> > > > > > issue (
> >> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
> >> > > > > > > > chatted
> >> > with
> >> > > > > > infra
> >> > > > > > > > and in response they created that issue.
> >> > > > > > > > >
> >> > > > > > > > > To expand on this discussion, I would like to toss
> >> > > > > > > > > out
> >> > another
> >> > > > > > > > alternative to discuss / explore. What if we used a
> >> > > > > > > > separate
> >> > > > GitHub
> >> > > > > > > > project, something like Accumulo-Design, just like
> >> > accumulo-proxy
> >> > > > and
> >> > > > > > > > accumulo-examples. As a separate project, it would be
> >> > available
> >> > > > for
> >> > > > > > > > collaboration for the community, but remain separate
> >> > > > > > > > from main
> >> > > > project
> >> > > > > > and
> >> > > > > > > > the website to keep current code / documentation /
> >> > > > > > > > design
> >> > clearly
> >> > > > > > separate
> >> > > > > > > > from speculative design discussions. As a project:
> >> > > > > > > > >
> >> > > > > > > > > - document history would be preserved with git commit
> >> > history.
> >> > > > > > > > > - document collaboration could be done with normal PR
> >> > > > submissions /
> >> > > > > > > > reviews.
> >> > > > > > > > > - issues could be used to discuss design aspects,
> >> > > > > > > > > capturing
> >> > the
> >> > > > > > comment
> >> > > > > > > > history.
> >> > > > > > > > >
> >> > > > > > > > > The biggest downside is that it would be yet another
> >> > > > > > > > > project
> >> > to
> >> > > > > > follow /
> >> > > > > > > > track.
> >> > > > > > > > >
> >> > > > > > > > > For me, I think the issue is that we need a public,
> >> > collaborative
> >> > > > > > space
> >> > > > > > > > to hold design discussions. Neither the main project or
> >> > > > > > > > the
> >> > > > web-site
> >> > > > > > seem
> >> > > > > > > > quite appropriate and Confluence seems to lack the
> >> > collaboration
> >> > > > that
> >> > > > > > can
> >> > > > > > > > be achieved with github.
> >> > > > > > > > >
> >> > > > > > > > > We need a space to capture the redesign and whatever
> >> > > > > > > > > we
> >> > select
> >> > > > can be
> >> > > > > > > > made to work - I'm just wondering what provides the
> >> > > > > > > > easiest
> >> > forum
> >> > > > to
> >> > > > > > build
> >> > > > > > > > a collaborative space for the Accumulo community.
> >> > > > > > > > >
> >> > > > > > > > > Ed Coleman
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> >> > > > > > > > > > Circling back on this issue - I agree that comments
> >> > > > > > > > > > and
> >> > such
> >> > > > make
> >> > > > > > > > sense for internal design documents. I'm going to
> >> > > > > > > > create an
> >> > INFRA
> >> > > > > > ticket
> >> > > > > > > > for a cwiki space for Accumulo unless there are any
> >> objections.
> >> > > > > > > > > >
> >> > > > > > > > > > -----Original Message-----
> >> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> >> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> >> > > > > > > > > > To: dev@accumulo.apache.org
> >> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> >> > > > > > > > > >
> >> > > > > > > > > > As mentioned, wikis can provide a streamlined
> >> > > > > > > > > > collaborative
> >> > > > editing
> >> > > > > > > > workflow that's less labor intensive than updating a
> >> website.
> >> > They
> >> > > > can
> >> > > > > > > > promote collaboration by providing specific tooling to
> >> > > > > > > > support
> >> > > > > > comments,
> >> > > > > > > > revisions and iteration.
> >> > > > > > > > > >
> >> > > > > > > > > > In terms of preservation, GH wikis act just like
> >> > > > > > > > > > any other
> >> > Git
> >> > > > > > > > repository, with a remote at (for example) git@github.com
> :
> >> > > > > > > > apache/accumulo.wiki.git
> >> > > > > > > > > > IIRC the pages are just GH flavored markdown. There
> >> > > > > > > > > > are at
> >> > > > least a
> >> > > > > > few
> >> > > > > > > > Apache projects using them.
> >> > > > > > > > > >
> >> > > > > > > > > > However, GH wikis lack some features that I feel
> >> > > > > > > > > > are
> >> > important
> >> > > > to
> >> > > > > > > > support collaborative authoring. For example, the
> >> > > > > > > > ability to
> >> > > > comment
> >> > > > > > and
> >> > > > > > > > discuss specific passages in a document is a feature
> >> > > > > > > > that's
> >> > > > present in
> >> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate this
> >> > > > > > > > this in
> >> > my
> >> > > > google
> >> > > > > > > > docs and office workflows, so expect that it would be
> >> > > > > > > > useful
> >> > for
> >> > > > > > Accumulo
> >> > > > > > > > design discussions too.
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> >> > > > kturner@apache.org>
> >> > > > > > > > wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > I would like to try a wiki for design documents,
> >> > > > > > > > > > > I think
> >> > it
> >> > > > > > would be
> >> > > > > > > > > > > less cumbersome than the website and we can
> >> > > > > > > > > > > always link
> >> > from
> >> > > > the
> >> > > > > > > > > > > website and issues to the wiki. I think its ok
> >> > > > > > > > > > > to give
> >> > it a
> >> > > > try
> >> > > > > > and
> >> > > > > > > > > > > abandon it in the future, if abandoned would just
> >> > > > > > > > > > > need to
> >> > > > > > properly
> >> > > > > > > > > > > communicate that. The content should be archived
> >> > > > > > > > > > > in
> >> > Apache
> >> > > > > > > > > > > infrastructure, so if GH wiki does not do that
> >> > > > > > > > > > > then we
> >> > should
> >> > > > > > not use
> >> > > > > > > > > > > it. If GH wiki is not an option then could try
> cwiki.
> >> > > > > > > > > > >
> >> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> >> > > > > > > > > > > <dl...@comcast.net>
> >> > > > wrote:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > I reverted the change. I didn't think it would
> >> > > > > > > > > > > > be a big
> >> > > > deal,
> >> > > > > > but
> >> > > > > > > > if
> >> > > > > > > > > > > > it
> >> > > > > > > > > > > requires discussion, then let's discuss it.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > I'm looking for a place to host information
> >> > > > > > > > > > > > related to
> >> > > > internal
> >> > > > > > > > > > > > design
> >> > > > > > > > > > > discussions. I envision these to be living
> >> > > > > > > > > > > documents that
> >> > > > will be
> >> > > > > > > > > > > updated over time as the design/implementation
> >> > progresses and
> >> > > > > > that
> >> > > > > > > > > > > other committers will be able to comment on and
> >> > > > > > > > > > > edit. I
> >> > don't
> >> > > > > > feel
> >> > > > > > > > > > > that the website is the correct place for this
> >> because:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > 1. I don't think internal design discussions
> >> > > > > > > > > > > > should
> >> > go
> >> > > > on the
> >> > > > > > > > > > > > project
> >> > > > > > > > > > > website.
> >> > > > > > > > > > > > 2. Changes to the design documents could not
> >> > > > > > > > > > > > be seen
> >> > by
> >> > > > > > others
> >> > > > > > > > > > > > right
> >> > > > > > > > > > > away (IIRC changes to the website are built and
> >> > available at
> >> > > > > > > > > > > https://accumulo.staged.apache.org/, but human
> >> > intervention
> >> > > > is
> >> > > > > > > > > > > required to publish it at
> >> https://accumulo.apache.org/).
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > I looked in the INFRA issues and other projects
> >> > > > > > > > > > > > are
> >> > using
> >> > > > the
> >> > > > > > GH
> >> > > > > > > > > > > > Wiki
> >> > > > > > > > > > > feature and I saw no mention of backing it up or
> >> > > > > > > > > > > the
> >> > > > requirement
> >> > > > > > to
> >> > > > > > > > do
> >> > > > > > > > > > > so (maybe they rely on GitHub backing it up?). It
> >> > > > > > > > > > > does
> >> > appear
> >> > > > > > that we
> >> > > > > > > > > > > would need an INFRA ticket so that they can
> >> > > > > > > > > > > modify the
> >> > GitHub
> >> > > > > > project
> >> > > > > > > > > > > settings to lock the GitHub wiki down so that
> >> > > > > > > > > > > only
> >> > > > committers can
> >> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then
> >> > > > > > > > > > > I think
> >> > > > Apache
> >> > > > > > > > > > > Confluence (
> >> > > > > > > > > > > https://cwiki.apache.org) might be an acceptable
> >> > > > alternative.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > -----Original Message-----
> >> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> >> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> >> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> >> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> >> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> >> > > > > > > > > > > > Enable
> >> > Github
> >> > > > > > wiki in
> >> > > > > > > > > > > asf.yaml
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > I don't recall a discussion about this change,
> >> > > > > > > > > > > > but I
> >> > think
> >> > > > it
> >> > > > > > goes
> >> > > > > > > > > > > against previous efforts to make the website the
> >> > > > > > > > > > > one
> >> > > > canonical
> >> > > > > > > > > > > location for our documentation. I don't even
> >> > > > > > > > > > > think infra
> >> > is
> >> > > > > > backing
> >> > > > > > > > up
> >> > > > > > > > > > > wiki repos, so there wouldn't even be a record of
> >> > > > > > > > > > > the
> >> > wiki
> >> > > > > > contents
> >> > > > > > > > in
> >> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed up
> >> > > > > > > > > > > to
> >> > GitBox
> >> > > > and
> >> > > > > > the
> >> > > > > > > > > > > issue tracker, which CCs the notifications list).
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > In short, I think this should be reverted and
> >> > > > > > > > > > > > we
> >> > should not
> >> > > > > > use the
> >> > > > > > > > > > > GitHub wiki. If we need to store documents in a
> >> > > > > > > > > > > version
> >> > > > > > controlled
> >> > > > > > > > > > > way, we can store them on the website, or in our
> >> > project's
> >> > > > SVN
> >> > > > > > dev
> >> > > > > > > > > > > space. The wiki is just another place people
> >> > > > > > > > > > > would have
> >> > to
> >> > > > > > follow if
> >> > > > > > > > > > > they want to participate, and I don't think that
> >> > > > > > > > > > > serves
> >> > us.
> >> > > > > > > > Therefore,
> >> > > > > > > > > > > I think we shouldn't use it.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
> >> > > > > > > > > > > > <dl...@apache.org>
> >> > wrote:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > > This is an automated email from the ASF
> >> > > > > > > > > > > > > dual-hosted
> >> > git
> >> > > > > > > > repository.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
> >> > > > > > > > > > > > > repository
> >> > > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.
> >> > > > > > > > > > > > > git
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > The following commit(s) were added to
> >> > refs/heads/main by
> >> > > > this
> >> > > > > > > > push:
> >> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> >> > > > > > > > > > > > > asf.yaml
> >> > > > > > ae8a817e7b is
> >> > > > > > > > > > > > > described below
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > commit
> >> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> >> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> >> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> >> > > > > > > > > > > > > ---
> >> > > > > > > > > > > > > .asf.yaml | 2 +-
> >> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
> >> > > > > > > > > > > > > deletion(-)
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> >> > > > > > bc2c943e82..08aa357082
> >> > > > > > > > > > > > > 100644
> >> > > > > > > > > > > > > --- a/.asf.yaml
> >> > > > > > > > > > > > > +++ b/.asf.yaml
> >> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> >> > > > > > > > > > > > > - big-data
> >> > > > > > > > > > > > > - hacktoberfest
> >> > > > > > > > > > > > > features:
> >> > > > > > > > > > > > > - wiki: false
> >> > > > > > > > > > > > > + wiki: true
> >> > > > > > > > > > > > > issues: true
> >> > > > > > > > > > > > > projects: true
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > >
> >> > > > > >
> >> > > >
> >> >
> >>
> >
>
RE: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by dev1 <de...@etcoleman.com>.
I just tried (Wed, 3/15) and still received the same error. I asked on the infra slack channel and they replied that they are still working to determine what the issue is - signs are pointing to something inside of confluence, but no progress.
At this point, I think we should move forward with a GH wiki and then we can re-evaluate things once the Apache confluence issue is sorted out.
Ed Coleman
-----Original Message-----
From: Dave Marion <dm...@gmail.com>
Sent: Wednesday, March 8, 2023 11:09 AM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
Looking at the Infra slack channel response, one of the responses in the channel said that "it's some sort of db corruption according to Atlassian".
Doesn't sound good....
On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/INFRA-24291 is still unresolved
> and the only comment on the ticket is one that Ed added two days ago
> requesting an ACCUMULO wiki space.
>
> On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
>
>> I do not see any comments in the infa slack channel - so no updates
>> for now.
>>
>> -----Original Message-----
>> From: Dave Marion <dm...@gmail.com>
>> Sent: Friday, March 3, 2023 12:06 PM
>> To: dev@accumulo.apache.org
>> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>>
>> Right, I was just curious if there was any follow-up as I think Ed
>> said that it was going to be discussed by the INFRA team yesterday.
>> There is at least one other recent ticket (
>> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve
>> had an issue and the INFRA team created the space manually.
>>
>> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org> wrote:
>>
>> > You can track that issue at
>> > https://issues.apache.org/jira/browse/INFRA-24291
>> >
>> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com>
>> wrote:
>> > >
>> > > Ed,
>> > >
>> > > Any update from INFRA on being able to create confluence pages?
>> > >
>> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org>
>> wrote:
>> > >
>> > > > We've definitely used the website for more than that. We use it
>> > > > to document things for users, help developers know how to
>> > > > contribute, store drafts of designs, share user stories via
>> > > > blogs, do release announcements, and more. There's definitely
>> > > > space on the website to do this kind of thing, if we want to.
>> > > > We've used it that way before. If you only see it as a place
>> > > > "for user consumption after everything has been finalized",
>> > > > then you're missing out on the other ways we currently use the
>> > > > site, and the ways we've used it in
>> the past.
>> > > >
>> > > > With the website, most of the collaboration would happen in the
>> > > > GH issues about proposed designs or changes to designs, just
>> > > > like we do today with code or other documentation, which
>> > > > everybody is used to. I agree it's not as good as Google Docs
>> > > > for on-the-fly comments/annotations, but I don't think
>> > > > Confluence or Wiki are as good as that either, and Google Docs isn't really an option...
>> > > > unless you just want to link to it in the mailing list and
>> > > > stick to Google Docs from your personal Google account, until
>> > > > it's ready for publication, which would also be fine (any
>> > > > interested persons can simply request write access by replying
>> > > > to the message where
>> you shared the link)..
>> > > >
>> > > > We are a much smaller project than many others, and we have
>> > > > previously suffered from having stuff too spread out. Even if
>> > > > other projects find a separate space valuable for them, I'm not
>> > > > sure it's best for the Accumulo project. While I think it's
>> > > > useful to examine what other projects do, I do think we should
>> > > > be careful to adopt anything just because others find it convenient for them.
>> > > >
>> > > > Confluence is my second choice, but with a big gap between it
>> > > > and my first choice.
>> > > >
>> > > > On a personal note: I hate using Confluence, because I think
>> > > > the navigation is highly unintuitive, as is the permissions
>> > > > model, and I don't like the idea of learning yet another
>> > > > wiki-syntax (though I've read Confluence supports some limited
>> > > > Markdown, but probably not the same as GitHub/Jekyll). I also
>> > > > do not want to set up custom notifications for watching yet
>> > > > another space. If we use Confluence, I will probably contribute
>> > > > very infrequently there because of my frustrations with having
>> > > > used it before. However, that would be my choice, and should
>> > > > not be a reason the project chooses one over another. I'm
>> > > > sharing my personal opinion only because it is influencing my
>> > > > opinion about the website being more accessible, via our
>> > > > current GitHub PR/issue/Markdown workflows, and I wonder how
>> > > > many other potential contributors would feel similarly. It's
>> > > > hard to know, since it seems like a lot of this is subjective,
>> > > > and is going to come down to a consensus of personal
>> preferences.
>> > > >
>> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion
>> > > > <dm...@gmail.com>
>> > wrote:
>> > > > >
>> > > > > I don't see the website as an area where we would have
>> > > > > collaborative discussions about an idea. For example, making
>> > > > > comments and
>> > suggestions
>> > > > on
>> > > > > a document like you can do in Google Docs. I see the website
>> > > > > as a
>> > place
>> > > > > where items are documented for user consumption after
>> > > > > everything has
>> > been
>> > > > > finalized. I'm not trying to create a private discussion
>> > > > > area, I
>> > think
>> > > > > anyone can see the wiki (but I think anonymous comments are
>> > > > > disabled
>> > due
>> > > > to
>> > > > > spam issues). I see no issue with putting work-in-progress
>> > > > > documents
>> > on a
>> > > > > wiki and referencing them via emails to the dev list. I think
>> > > > > this is
>> > > > done
>> > > > > in a lot of other projects. Non-committers that don't have
>> > > > > access to
>> > the
>> > > > > wiki and want to make comments, suggestions, and ask
>> > > > > questions can
>> > do so
>> > > > > via the mailing list. I think it's also possible that people
>> > > > > can get confluence accounts (see
>> > > > https://issues.apache.org/jira/browse/INFRA-7058),
>> > > > > so if a non-committer wanted to participate they could.
>> > > > >
>> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher
>> > > > > <ct...@apache.org>
>> > wrote:
>> > > > >
>> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
>> > > > > > <dm...@gmail.com>
>> > > > wrote:
>> > > > > > >
>> > > > > > > I'm opposed to using the website for the reasons I
>> > > > > > > specified
>> > > > earlier, so
>> > > > > > it
>> > > > > >
>> > > > > > Your reasons that I saw were:
>> > > > > >
>> > > > > > > 1. I don't think internal design discussions should go on
>> > > > > > > the
>> > project
>> > > > > > website.
>> > > > > >
>> > > > > > That doesn't look to me like a reason. That appears to just
>> > > > > > be
>> > stating
>> > > > > > the conclusion. Did I miss your reason here?
>> > > > > >
>> > > > > > > 2. Changes to the design documents could not be seen by
>> > > > > > > others
>> > right
>> > > > > > away (IIRC changes to the website are built and available
>> > > > > > at https://accumulo.staged.apache.org/, but human
>> > > > > > intervention is
>> > > > required
>> > > > > > to publish it at https://accumulo.apache.org/).
>> > > > > >
>> > > > > > What do you mean by "others" here? Do you mean "users", as
>> > > > > > opposed
>> > to
>> > > > > > "developers/contributors"? The ASF draws a distinction
>> > > > > > between "developers/contributors" and "users" as it
>> > > > > > pertains to official releases. Releases are intended to be
>> > > > > > consumed by users, and pre-release stuff is intended to be
>> > > > > > collaborative, open to all potential
>> > > > > > developers/contributors. Very very rarely are things
>> > > > > > reserved exclusively for committers. We don't even have a
>> > > > > > private committers space (the private mailing list is
>> > > > > > PMC-private, not committer-private). Having a distinction
>> > > > > > between users and
>> > developers
>> > > > > > doesn't mean we can't publish things on the website... it
>> > > > > > just
>> > means
>> > > > > > that we should be careful about how we do it, which is the
>> > > > > > same
>> > care
>> > > > > > we should take regardless of where we put it. Specifically,
>> > > > > > the
>> > care
>> > > > > > we need to take is to avoid marketing pre-release content
>> > > > > > to
>> users.
>> > > > > > One way we can exercise this care for content on our
>> > > > > > website is
>> > that
>> > > > > > we can avoid sharing these unpolished designs by simply not
>> > > > > > linking them on the site, or by placing them in an area
>> > > > > > that is clearly
>> > marked
>> > > > > > as intended for devs. But, we have no similar distinction
>> > > > > > between committers and non-committer devs for which we
>> > > > > > should avoid sharing pre-release content under development.
>> > > > > > In fact, it is the
>> > opposite...
>> > > > > > we should be developing openly so as to allow room for
>> > non-committers
>> > > > > > to become committers through participation in development
>> > activities.
>> > > > > >
>> > > > > > As for the staging/publication of the website, that's just
>> > > > > > a
>> > mechanic
>> > > > > > for verifying the website isn't broken before we serve it.
>> > > > > > It's
>> > not a
>> > > > > > mechanism for keeping things internal vs. shared and
>> > > > > > doesn't have anything to do with the separation between
>> > > > > > devs and users. We
>> > already
>> > > > > > publish Draft contents to the website, as well as
>> > developer-specific
>> > > > > > documentation not intended for users.
>> > > > > >
>> > > > > > We've even specifically published work-in-progress design
>> > > > > > documents there, of the same type that seems to be the
>> > > > > > basis of this conversation (
>> https://accumulo.apache.org/design/system-snapshot).
>> > I
>> > > > > > would strongly prefer us to continue to do it this way,
>> > > > > > rather than create a new space, and have these kinds of
>> > > > > > things scattered in multiple places.
>> > > > > >
>> > > > > > If, on the other hand, you intend to say that these should
>> > > > > > be
>> > private
>> > > > > > because they aren't ready for other potential contributors,
>> > > > > > then I would argue that we're an openly developed project...
>> > > > > > if something isn't ready to be shared with other potential
>> > > > > > contributors / developers, such that you want to keep it
>> > > > > > internal to existing committers, then it's not ready to be
>> > > > > > contributed to the project at all... because we don't
>> > > > > > restrict collaboration to only existing committers. That
>> > > > > > would prevent others from participating and
>> > earning
>> > > > > > the merit to become committers, and that's not something we
>> > > > > > should
>> > be
>> > > > > > doing. Anything that is okay to share with existing
>> > > > > > committers
>> > should
>> > > > > > be okay to share to other potential contributors who want
>> > > > > > to participate, and should be done in a space that allows
>> > > > > > them to do that. The website is a perfect space for that,
>> > > > > > and has everything
>> > we
>> > > > > > need. I'm actually not sure about Confluence... I suspect
>> > > > > > non-committers wouldn't be able to participate there
>> > > > > > because they probably can't get accounts for it.
>> > > > > >
>> > > > > >
>> > > > > > > looks like we need to
>> > > > > > > wait for INFRA to fix Confluence. I'd be curious how much
>> > > > > > > we
>> > need to
>> > > > use
>> > > > > > > the mailing list during
>> > > > > > > the design phase. We can announce meeting dates/times on
>> > > > > > > the
>> > mailing
>> > > > list
>> > > > > > > and post links to
>> > > > > > > meeting notes in Confluence. Ultimately, decisions made
>> > > > > > > by the
>> > people
>> > > > > > that
>> > > > > > > want to be involved
>> > > > > > > will turn into pull requests against the codebase which
>> > comitters can
>> > > > > > weigh
>> > > > > > > in on. When you say,
>> > > > > > > "... but decisions about those would still need to be
>> > > > > > > done on the
>> > > > mailing
>> > > > > > > list." Are you saying that we need to discuss every
>> > > > > > > single design decision on the mailing
>> > list?
>> > > > > >
>> > > > > > Yes and no. I am saying that decisions need to happen on
>> > > > > > the
>> > mailing
>> > > > > > list, but I agree with you that this can be satisfied
>> > > > > > through pull requests. I just wanted to emphasize that
>> > > > > > regardless of where we do that pre-decision collaboration,
>> > > > > > that collaboration should not be misconstrued as a decision
>> > > > > > to
>> accept those ideas into the project.
>> > The
>> > > > > > decision occurs during the PR or other activity that
>> > > > > > interfaces
>> > with
>> > > > > > the mailing list, subsequent to the collaboration in the
>> > design/idea
>> > > > > > phase.
>> > > > > >
>> > > > > > As for the pre-decision collaboration space we're
>> > > > > > discussing, I
>> > just
>> > > > > > want to be careful that we're not creating such a space in
>> > > > > > an exclusionary way that allows only existing committers to
>> > participate,
>> > > > > > that excludes other potential contributors. This is still
>> > > > > > an openly-developed project, and we should collaborate in a
>> > > > > > space
>> > that is
>> > > > > > not exclusive to existing committers, but open to
>> > > > > > non-committer contributors and potential contributors as well.
>> > > > > > So, while we may
>> > want
>> > > > > > to keep a line separating dev activity from user
>> > > > > > consumption (an important separation that relates to
>> > > > > > official ASF releases), we
>> > should
>> > > > > > not be drawing a line between committer-devs as "internal"
>> > > > > > and contributor-devs as "external". The website, with its
>> > > > > > own issue tracker, the ability to render markdown, do
>> > > > > > reviews, and collaboratively edit, seems like the ideal
>> > > > > > place to me. We've used
>> > it
>> > > > > > before for the same purpose, and I think we should continue
>> > > > > > to do
>> > so.
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
>> > > > > > > <ctubbsii@apache.org
>> > >
>> > > > wrote:
>> > > > > > >
>> > > > > > > > So, I agree a space would be helpful. Although it's old
>> > > > > > > > school
>> > and
>> > > > > > > > inconvenient, the mailing list is the canonical place
>> > > > > > > > for
>> > > > discussion.
>> > > > > > > > We currently use GitHub issues a lot, but that's copied
>> > > > > > > > to a
>> > > > mailing
>> > > > > > > > list (as is our old JIRA space), so if people want to
>> > participate
>> > > > > > > > without a GitHub account, they can still do that. There
>> > > > > > > > are
>> > certain
>> > > > > > > > options that are perhaps less convenient, such as just
>> > > > > > > > using
>> > the
>> > > > > > > > mailing list and our dev SVN space, but still more
>> > > > > > > > appropriate
>> > than
>> > > > > > > > options that would be less ubiquitous for potential
>> > participants.
>> > > > > > > >
>> > > > > > > > I think the ASF Confluence is probably fine, for
>> > > > > > > > storing,
>> > editing,
>> > > > and
>> > > > > > > > collaborating on shared documents, but decisions about
>> > > > > > > > those
>> > would
>> > > > > > > > still need to be done on the mailing list. If I
>> > > > > > > > remember
>> > > > correctly, we
>> > > > > > > > used to have a Wiki space, prior to it being
>> > > > > > > > transferred to Confluence, but it was poorly
>> > > > > > > > maintained, so we abandoned it in
>> > > > favor
>> > > > > > > > of using the website for docs. I could be
>> > > > > > > > mis-remembering, but
>> > I
>> > > > think
>> > > > > > > > this is the case. It might explain why you can't create
>> > > > > > > > a
>> > > > Confluence
>> > > > > > > > space.
>> > > > > > > >
>> > > > > > > > My preference would be to just use the website. I think
>> > > > > > > > it's
>> > fine
>> > > > to
>> > > > > > > > have a dev / design area of the website, and we can
>> > > > > > > > discuss on
>> > > > GitHub
>> > > > > > > > issues for the accumulo-website repo. That is a bit
>> > > > > > > > less
>> > convenient
>> > > > > > > > than Confluence if it's used heavily, but it's more
>> > > > > > > > convenient
>> > in
>> > > > the
>> > > > > > > > sense that it's more accessible and fits more in line
>> > > > > > > > with our
>> > > > current
>> > > > > > > > mode of operation. Plus, when a document is final, it's
>> > > > > > > > easy to
>> > > > link
>> > > > > > > > to from our documentation, without making users jump to
>> > > > > > > > another service to view docs.
>> > > > > > > >
>> > > > > > > > I would be opposed to using GitHub wiki or a new git repo.
>> > > > > > > > We
>> > have
>> > > > > > > > enough repos. Although it seems like they are free,
>> > > > > > > > there is
>> > still
>> > > > a
>> > > > > > > > lot of boilerplate work to maintain them, from managing
>> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
>> > .asf.yaml, to
>> > > > > > > > README, to keeping copyright dates updated in the
>> > > > > > > > NOTICE file,
>> > and
>> > > > > > > > more.
>> > > > > > > >
>> > > > > > > > In summary, my preference:
>> > > > > > > >
>> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH
>> > > > > > > > issues and
>> > > > mailing
>> > > > > > > > list (strongly preferred) 2. Confluence, discuss on
>> > > > > > > > mailing list (prefer over other
>> > options,
>> > > > but
>> > > > > > > > not a fan)
>> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly
>> > > > > > > > prefer not
>> > to use
>> > > > > > this
>> > > > > > > > option)
>> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing
>> > > > > > > > list
>> > (strongly
>> > > > > > > > prefer not to use this option)
>> > > > > > > >
>> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
>> > edcoleman@apache.org>
>> > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > Currently, asf cannot create new wiki's because of a
>> > Confluence
>> > > > > > issue (
>> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
>> > > > > > > > chatted
>> > with
>> > > > > > infra
>> > > > > > > > and in response they created that issue.
>> > > > > > > > >
>> > > > > > > > > To expand on this discussion, I would like to toss
>> > > > > > > > > out
>> > another
>> > > > > > > > alternative to discuss / explore. What if we used a
>> > > > > > > > separate
>> > > > GitHub
>> > > > > > > > project, something like Accumulo-Design, just like
>> > accumulo-proxy
>> > > > and
>> > > > > > > > accumulo-examples. As a separate project, it would be
>> > available
>> > > > for
>> > > > > > > > collaboration for the community, but remain separate
>> > > > > > > > from main
>> > > > project
>> > > > > > and
>> > > > > > > > the website to keep current code / documentation /
>> > > > > > > > design
>> > clearly
>> > > > > > separate
>> > > > > > > > from speculative design discussions. As a project:
>> > > > > > > > >
>> > > > > > > > > - document history would be preserved with git commit
>> > history.
>> > > > > > > > > - document collaboration could be done with normal PR
>> > > > submissions /
>> > > > > > > > reviews.
>> > > > > > > > > - issues could be used to discuss design aspects,
>> > > > > > > > > capturing
>> > the
>> > > > > > comment
>> > > > > > > > history.
>> > > > > > > > >
>> > > > > > > > > The biggest downside is that it would be yet another
>> > > > > > > > > project
>> > to
>> > > > > > follow /
>> > > > > > > > track.
>> > > > > > > > >
>> > > > > > > > > For me, I think the issue is that we need a public,
>> > collaborative
>> > > > > > space
>> > > > > > > > to hold design discussions. Neither the main project or
>> > > > > > > > the
>> > > > web-site
>> > > > > > seem
>> > > > > > > > quite appropriate and Confluence seems to lack the
>> > collaboration
>> > > > that
>> > > > > > can
>> > > > > > > > be achieved with github.
>> > > > > > > > >
>> > > > > > > > > We need a space to capture the redesign and whatever
>> > > > > > > > > we
>> > select
>> > > > can be
>> > > > > > > > made to work - I'm just wondering what provides the
>> > > > > > > > easiest
>> > forum
>> > > > to
>> > > > > > build
>> > > > > > > > a collaborative space for the Accumulo community.
>> > > > > > > > >
>> > > > > > > > > Ed Coleman
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
>> > > > > > > > > > Circling back on this issue - I agree that comments
>> > > > > > > > > > and
>> > such
>> > > > make
>> > > > > > > > sense for internal design documents. I'm going to
>> > > > > > > > create an
>> > INFRA
>> > > > > > ticket
>> > > > > > > > for a cwiki space for Accumulo unless there are any
>> objections.
>> > > > > > > > > >
>> > > > > > > > > > -----Original Message-----
>> > > > > > > > > > From: Drew Farris <dr...@ill.org>
>> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
>> > > > > > > > > > To: dev@accumulo.apache.org
>> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>> > > > > > > > > >
>> > > > > > > > > > As mentioned, wikis can provide a streamlined
>> > > > > > > > > > collaborative
>> > > > editing
>> > > > > > > > workflow that's less labor intensive than updating a
>> website.
>> > They
>> > > > can
>> > > > > > > > promote collaboration by providing specific tooling to
>> > > > > > > > support
>> > > > > > comments,
>> > > > > > > > revisions and iteration.
>> > > > > > > > > >
>> > > > > > > > > > In terms of preservation, GH wikis act just like
>> > > > > > > > > > any other
>> > Git
>> > > > > > > > repository, with a remote at (for example) git@github.com:
>> > > > > > > > apache/accumulo.wiki.git
>> > > > > > > > > > IIRC the pages are just GH flavored markdown. There
>> > > > > > > > > > are at
>> > > > least a
>> > > > > > few
>> > > > > > > > Apache projects using them.
>> > > > > > > > > >
>> > > > > > > > > > However, GH wikis lack some features that I feel
>> > > > > > > > > > are
>> > important
>> > > > to
>> > > > > > > > support collaborative authoring. For example, the
>> > > > > > > > ability to
>> > > > comment
>> > > > > > and
>> > > > > > > > discuss specific passages in a document is a feature
>> > > > > > > > that's
>> > > > present in
>> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate this
>> > > > > > > > this in
>> > my
>> > > > google
>> > > > > > > > docs and office workflows, so expect that it would be
>> > > > > > > > useful
>> > for
>> > > > > > Accumulo
>> > > > > > > > design discussions too.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
>> > > > kturner@apache.org>
>> > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > I would like to try a wiki for design documents,
>> > > > > > > > > > > I think
>> > it
>> > > > > > would be
>> > > > > > > > > > > less cumbersome than the website and we can
>> > > > > > > > > > > always link
>> > from
>> > > > the
>> > > > > > > > > > > website and issues to the wiki. I think its ok
>> > > > > > > > > > > to give
>> > it a
>> > > > try
>> > > > > > and
>> > > > > > > > > > > abandon it in the future, if abandoned would just
>> > > > > > > > > > > need to
>> > > > > > properly
>> > > > > > > > > > > communicate that. The content should be archived
>> > > > > > > > > > > in
>> > Apache
>> > > > > > > > > > > infrastructure, so if GH wiki does not do that
>> > > > > > > > > > > then we
>> > should
>> > > > > > not use
>> > > > > > > > > > > it. If GH wiki is not an option then could try cwiki.
>> > > > > > > > > > >
>> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
>> > > > > > > > > > > <dl...@comcast.net>
>> > > > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > I reverted the change. I didn't think it would
>> > > > > > > > > > > > be a big
>> > > > deal,
>> > > > > > but
>> > > > > > > > if
>> > > > > > > > > > > > it
>> > > > > > > > > > > requires discussion, then let's discuss it.
>> > > > > > > > > > > >
>> > > > > > > > > > > > I'm looking for a place to host information
>> > > > > > > > > > > > related to
>> > > > internal
>> > > > > > > > > > > > design
>> > > > > > > > > > > discussions. I envision these to be living
>> > > > > > > > > > > documents that
>> > > > will be
>> > > > > > > > > > > updated over time as the design/implementation
>> > progresses and
>> > > > > > that
>> > > > > > > > > > > other committers will be able to comment on and
>> > > > > > > > > > > edit. I
>> > don't
>> > > > > > feel
>> > > > > > > > > > > that the website is the correct place for this
>> because:
>> > > > > > > > > > > >
>> > > > > > > > > > > > 1. I don't think internal design discussions
>> > > > > > > > > > > > should
>> > go
>> > > > on the
>> > > > > > > > > > > > project
>> > > > > > > > > > > website.
>> > > > > > > > > > > > 2. Changes to the design documents could not
>> > > > > > > > > > > > be seen
>> > by
>> > > > > > others
>> > > > > > > > > > > > right
>> > > > > > > > > > > away (IIRC changes to the website are built and
>> > available at
>> > > > > > > > > > > https://accumulo.staged.apache.org/, but human
>> > intervention
>> > > > is
>> > > > > > > > > > > required to publish it at
>> https://accumulo.apache.org/).
>> > > > > > > > > > > >
>> > > > > > > > > > > > I looked in the INFRA issues and other projects
>> > > > > > > > > > > > are
>> > using
>> > > > the
>> > > > > > GH
>> > > > > > > > > > > > Wiki
>> > > > > > > > > > > feature and I saw no mention of backing it up or
>> > > > > > > > > > > the
>> > > > requirement
>> > > > > > to
>> > > > > > > > do
>> > > > > > > > > > > so (maybe they rely on GitHub backing it up?). It
>> > > > > > > > > > > does
>> > appear
>> > > > > > that we
>> > > > > > > > > > > would need an INFRA ticket so that they can
>> > > > > > > > > > > modify the
>> > GitHub
>> > > > > > project
>> > > > > > > > > > > settings to lock the GitHub wiki down so that
>> > > > > > > > > > > only
>> > > > committers can
>> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then
>> > > > > > > > > > > I think
>> > > > Apache
>> > > > > > > > > > > Confluence (
>> > > > > > > > > > > https://cwiki.apache.org) might be an acceptable
>> > > > alternative.
>> > > > > > > > > > > >
>> > > > > > > > > > > > -----Original Message-----
>> > > > > > > > > > > > From: Christopher <ct...@apache.org>
>> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
>> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
>> > > > > > > > > > > > Cc: commits@accumulo.apache.org
>> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
>> > > > > > > > > > > > Enable
>> > Github
>> > > > > > wiki in
>> > > > > > > > > > > asf.yaml
>> > > > > > > > > > > >
>> > > > > > > > > > > > I don't recall a discussion about this change,
>> > > > > > > > > > > > but I
>> > think
>> > > > it
>> > > > > > goes
>> > > > > > > > > > > against previous efforts to make the website the
>> > > > > > > > > > > one
>> > > > canonical
>> > > > > > > > > > > location for our documentation. I don't even
>> > > > > > > > > > > think infra
>> > is
>> > > > > > backing
>> > > > > > > > up
>> > > > > > > > > > > wiki repos, so there wouldn't even be a record of
>> > > > > > > > > > > the
>> > wiki
>> > > > > > contents
>> > > > > > > > in
>> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed up
>> > > > > > > > > > > to
>> > GitBox
>> > > > and
>> > > > > > the
>> > > > > > > > > > > issue tracker, which CCs the notifications list).
>> > > > > > > > > > > >
>> > > > > > > > > > > > In short, I think this should be reverted and
>> > > > > > > > > > > > we
>> > should not
>> > > > > > use the
>> > > > > > > > > > > GitHub wiki. If we need to store documents in a
>> > > > > > > > > > > version
>> > > > > > controlled
>> > > > > > > > > > > way, we can store them on the website, or in our
>> > project's
>> > > > SVN
>> > > > > > dev
>> > > > > > > > > > > space. The wiki is just another place people
>> > > > > > > > > > > would have
>> > to
>> > > > > > follow if
>> > > > > > > > > > > they want to participate, and I don't think that
>> > > > > > > > > > > serves
>> > us.
>> > > > > > > > Therefore,
>> > > > > > > > > > > I think we shouldn't use it.
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59
>> > > > > > > > > > > > <dl...@apache.org>
>> > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > > This is an automated email from the ASF
>> > > > > > > > > > > > > dual-hosted
>> > git
>> > > > > > > > repository.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
>> > > > > > > > > > > > > repository
>> > > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.
>> > > > > > > > > > > > > git
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > The following commit(s) were added to
>> > refs/heads/main by
>> > > > this
>> > > > > > > > push:
>> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
>> > > > > > > > > > > > > asf.yaml
>> > > > > > ae8a817e7b is
>> > > > > > > > > > > > > described below
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > commit
>> > > > > > > > > > > > > ae8a817e7b2af8c64096ed1a4274eaef44c0e677
>> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
>> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Enable Github wiki in asf.yaml
>> > > > > > > > > > > > > ---
>> > > > > > > > > > > > > .asf.yaml | 2 +-
>> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1
>> > > > > > > > > > > > > deletion(-)
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
>> > > > > > bc2c943e82..08aa357082
>> > > > > > > > > > > > > 100644
>> > > > > > > > > > > > > --- a/.asf.yaml
>> > > > > > > > > > > > > +++ b/.asf.yaml
>> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
>> > > > > > > > > > > > > - big-data
>> > > > > > > > > > > > > - hacktoberfest
>> > > > > > > > > > > > > features:
>> > > > > > > > > > > > > - wiki: false
>> > > > > > > > > > > > > + wiki: true
>> > > > > > > > > > > > > issues: true
>> > > > > > > > > > > > > projects: true
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > >
>> >
>>
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
Looking at the Infra slack channel response, one of the responses in the
channel said that "it's some sort of db corruption according to Atlassian".
Doesn't sound good....
On Wed, Mar 8, 2023 at 10:55 AM Dave Marion <dm...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/INFRA-24291 is still unresolved and
> the only comment on the ticket is one that Ed added two days ago requesting
> an ACCUMULO wiki space.
>
> On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
>
>> I do not see any comments in the infa slack channel - so no updates for
>> now.
>>
>> -----Original Message-----
>> From: Dave Marion <dm...@gmail.com>
>> Sent: Friday, March 3, 2023 12:06 PM
>> To: dev@accumulo.apache.org
>> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>>
>> Right, I was just curious if there was any follow-up as I think Ed said
>> that it was going to be discussed by the INFRA team yesterday. There is at
>> least one other recent ticket (
>> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve had
>> an issue and the INFRA team created the space manually.
>>
>> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org> wrote:
>>
>> > You can track that issue at
>> > https://issues.apache.org/jira/browse/INFRA-24291
>> >
>> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com>
>> wrote:
>> > >
>> > > Ed,
>> > >
>> > > Any update from INFRA on being able to create confluence pages?
>> > >
>> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org>
>> wrote:
>> > >
>> > > > We've definitely used the website for more than that. We use it to
>> > > > document things for users, help developers know how to contribute,
>> > > > store drafts of designs, share user stories via blogs, do release
>> > > > announcements, and more. There's definitely space on the website
>> > > > to do this kind of thing, if we want to. We've used it that way
>> > > > before. If you only see it as a place "for user consumption after
>> > > > everything has been finalized", then you're missing out on the
>> > > > other ways we currently use the site, and the ways we've used it in
>> the past.
>> > > >
>> > > > With the website, most of the collaboration would happen in the GH
>> > > > issues about proposed designs or changes to designs, just like we
>> > > > do today with code or other documentation, which everybody is used
>> > > > to. I agree it's not as good as Google Docs for on-the-fly
>> > > > comments/annotations, but I don't think Confluence or Wiki are as
>> > > > good as that either, and Google Docs isn't really an option...
>> > > > unless you just want to link to it in the mailing list and stick
>> > > > to Google Docs from your personal Google account, until it's ready
>> > > > for publication, which would also be fine (any interested persons
>> > > > can simply request write access by replying to the message where
>> you shared the link)..
>> > > >
>> > > > We are a much smaller project than many others, and we have
>> > > > previously suffered from having stuff too spread out. Even if
>> > > > other projects find a separate space valuable for them, I'm not
>> > > > sure it's best for the Accumulo project. While I think it's useful
>> > > > to examine what other projects do, I do think we should be careful
>> > > > to adopt anything just because others find it convenient for them.
>> > > >
>> > > > Confluence is my second choice, but with a big gap between it and
>> > > > my first choice.
>> > > >
>> > > > On a personal note: I hate using Confluence, because I think the
>> > > > navigation is highly unintuitive, as is the permissions model, and
>> > > > I don't like the idea of learning yet another wiki-syntax (though
>> > > > I've read Confluence supports some limited Markdown, but probably
>> > > > not the same as GitHub/Jekyll). I also do not want to set up
>> > > > custom notifications for watching yet another space. If we use
>> > > > Confluence, I will probably contribute very infrequently there
>> > > > because of my frustrations with having used it before. However,
>> > > > that would be my choice, and should not be a reason the project
>> > > > chooses one over another. I'm sharing my personal opinion only
>> > > > because it is influencing my opinion about the website being more
>> > > > accessible, via our current GitHub PR/issue/Markdown workflows,
>> > > > and I wonder how many other potential contributors would feel
>> > > > similarly. It's hard to know, since it seems like a lot of this is
>> > > > subjective, and is going to come down to a consensus of personal
>> preferences.
>> > > >
>> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com>
>> > wrote:
>> > > > >
>> > > > > I don't see the website as an area where we would have
>> > > > > collaborative discussions about an idea. For example, making
>> > > > > comments and
>> > suggestions
>> > > > on
>> > > > > a document like you can do in Google Docs. I see the website as
>> > > > > a
>> > place
>> > > > > where items are documented for user consumption after everything
>> > > > > has
>> > been
>> > > > > finalized. I'm not trying to create a private discussion area, I
>> > think
>> > > > > anyone can see the wiki (but I think anonymous comments are
>> > > > > disabled
>> > due
>> > > > to
>> > > > > spam issues). I see no issue with putting work-in-progress
>> > > > > documents
>> > on a
>> > > > > wiki and referencing them via emails to the dev list. I think
>> > > > > this is
>> > > > done
>> > > > > in a lot of other projects. Non-committers that don't have
>> > > > > access to
>> > the
>> > > > > wiki and want to make comments, suggestions, and ask questions
>> > > > > can
>> > do so
>> > > > > via the mailing list. I think it's also possible that people can
>> > > > > get confluence accounts (see
>> > > > https://issues.apache.org/jira/browse/INFRA-7058),
>> > > > > so if a non-committer wanted to participate they could.
>> > > > >
>> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org>
>> > wrote:
>> > > > >
>> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
>> > > > > > <dm...@gmail.com>
>> > > > wrote:
>> > > > > > >
>> > > > > > > I'm opposed to using the website for the reasons I specified
>> > > > earlier, so
>> > > > > > it
>> > > > > >
>> > > > > > Your reasons that I saw were:
>> > > > > >
>> > > > > > > 1. I don't think internal design discussions should go on
>> > > > > > > the
>> > project
>> > > > > > website.
>> > > > > >
>> > > > > > That doesn't look to me like a reason. That appears to just be
>> > stating
>> > > > > > the conclusion. Did I miss your reason here?
>> > > > > >
>> > > > > > > 2. Changes to the design documents could not be seen by
>> > > > > > > others
>> > right
>> > > > > > away (IIRC changes to the website are built and available at
>> > > > > > https://accumulo.staged.apache.org/, but human intervention is
>> > > > required
>> > > > > > to publish it at https://accumulo.apache.org/).
>> > > > > >
>> > > > > > What do you mean by "others" here? Do you mean "users", as
>> > > > > > opposed
>> > to
>> > > > > > "developers/contributors"? The ASF draws a distinction between
>> > > > > > "developers/contributors" and "users" as it pertains to
>> > > > > > official releases. Releases are intended to be consumed by
>> > > > > > users, and pre-release stuff is intended to be collaborative,
>> > > > > > open to all potential developers/contributors. Very very
>> > > > > > rarely are things reserved exclusively for committers. We
>> > > > > > don't even have a private committers space (the private
>> > > > > > mailing list is PMC-private, not committer-private). Having a
>> > > > > > distinction between users and
>> > developers
>> > > > > > doesn't mean we can't publish things on the website... it just
>> > means
>> > > > > > that we should be careful about how we do it, which is the
>> > > > > > same
>> > care
>> > > > > > we should take regardless of where we put it. Specifically,
>> > > > > > the
>> > care
>> > > > > > we need to take is to avoid marketing pre-release content to
>> users.
>> > > > > > One way we can exercise this care for content on our website
>> > > > > > is
>> > that
>> > > > > > we can avoid sharing these unpolished designs by simply not
>> > > > > > linking them on the site, or by placing them in an area that
>> > > > > > is clearly
>> > marked
>> > > > > > as intended for devs. But, we have no similar distinction
>> > > > > > between committers and non-committer devs for which we should
>> > > > > > avoid sharing pre-release content under development. In fact,
>> > > > > > it is the
>> > opposite...
>> > > > > > we should be developing openly so as to allow room for
>> > non-committers
>> > > > > > to become committers through participation in development
>> > activities.
>> > > > > >
>> > > > > > As for the staging/publication of the website, that's just a
>> > mechanic
>> > > > > > for verifying the website isn't broken before we serve it.
>> > > > > > It's
>> > not a
>> > > > > > mechanism for keeping things internal vs. shared and doesn't
>> > > > > > have anything to do with the separation between devs and
>> > > > > > users. We
>> > already
>> > > > > > publish Draft contents to the website, as well as
>> > developer-specific
>> > > > > > documentation not intended for users.
>> > > > > >
>> > > > > > We've even specifically published work-in-progress design
>> > > > > > documents there, of the same type that seems to be the basis
>> > > > > > of this conversation (
>> https://accumulo.apache.org/design/system-snapshot).
>> > I
>> > > > > > would strongly prefer us to continue to do it this way, rather
>> > > > > > than create a new space, and have these kinds of things
>> > > > > > scattered in multiple places.
>> > > > > >
>> > > > > > If, on the other hand, you intend to say that these should be
>> > private
>> > > > > > because they aren't ready for other potential contributors,
>> > > > > > then I would argue that we're an openly developed project...
>> > > > > > if something isn't ready to be shared with other potential
>> > > > > > contributors / developers, such that you want to keep it
>> > > > > > internal to existing committers, then it's not ready to be
>> > > > > > contributed to the project at all... because we don't restrict
>> > > > > > collaboration to only existing committers. That would prevent
>> > > > > > others from participating and
>> > earning
>> > > > > > the merit to become committers, and that's not something we
>> > > > > > should
>> > be
>> > > > > > doing. Anything that is okay to share with existing committers
>> > should
>> > > > > > be okay to share to other potential contributors who want to
>> > > > > > participate, and should be done in a space that allows them to
>> > > > > > do that. The website is a perfect space for that, and has
>> > > > > > everything
>> > we
>> > > > > > need. I'm actually not sure about Confluence... I suspect
>> > > > > > non-committers wouldn't be able to participate there because
>> > > > > > they probably can't get accounts for it.
>> > > > > >
>> > > > > >
>> > > > > > > looks like we need to
>> > > > > > > wait for INFRA to fix Confluence. I'd be curious how much we
>> > need to
>> > > > use
>> > > > > > > the mailing list during
>> > > > > > > the design phase. We can announce meeting dates/times on the
>> > mailing
>> > > > list
>> > > > > > > and post links to
>> > > > > > > meeting notes in Confluence. Ultimately, decisions made by
>> > > > > > > the
>> > people
>> > > > > > that
>> > > > > > > want to be involved
>> > > > > > > will turn into pull requests against the codebase which
>> > comitters can
>> > > > > > weigh
>> > > > > > > in on. When you say,
>> > > > > > > "... but decisions about those would still need to be done
>> > > > > > > on the
>> > > > mailing
>> > > > > > > list." Are you saying that
>> > > > > > > we need to discuss every single design decision on the
>> > > > > > > mailing
>> > list?
>> > > > > >
>> > > > > > Yes and no. I am saying that decisions need to happen on the
>> > mailing
>> > > > > > list, but I agree with you that this can be satisfied through
>> > > > > > pull requests. I just wanted to emphasize that regardless of
>> > > > > > where we do that pre-decision collaboration, that
>> > > > > > collaboration should not be misconstrued as a decision to
>> accept those ideas into the project.
>> > The
>> > > > > > decision occurs during the PR or other activity that
>> > > > > > interfaces
>> > with
>> > > > > > the mailing list, subsequent to the collaboration in the
>> > design/idea
>> > > > > > phase.
>> > > > > >
>> > > > > > As for the pre-decision collaboration space we're discussing,
>> > > > > > I
>> > just
>> > > > > > want to be careful that we're not creating such a space in an
>> > > > > > exclusionary way that allows only existing committers to
>> > participate,
>> > > > > > that excludes other potential contributors. This is still an
>> > > > > > openly-developed project, and we should collaborate in a space
>> > that is
>> > > > > > not exclusive to existing committers, but open to
>> > > > > > non-committer contributors and potential contributors as well.
>> > > > > > So, while we may
>> > want
>> > > > > > to keep a line separating dev activity from user consumption
>> > > > > > (an important separation that relates to official ASF
>> > > > > > releases), we
>> > should
>> > > > > > not be drawing a line between committer-devs as "internal" and
>> > > > > > contributor-devs as "external". The website, with its own
>> > > > > > issue tracker, the ability to render markdown, do reviews, and
>> > > > > > collaboratively edit, seems like the ideal place to me. We've
>> > > > > > used
>> > it
>> > > > > > before for the same purpose, and I think we should continue to
>> > > > > > do
>> > so.
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
>> > > > > > > <ctubbsii@apache.org
>> > >
>> > > > wrote:
>> > > > > > >
>> > > > > > > > So, I agree a space would be helpful. Although it's old
>> > > > > > > > school
>> > and
>> > > > > > > > inconvenient, the mailing list is the canonical place for
>> > > > discussion.
>> > > > > > > > We currently use GitHub issues a lot, but that's copied to
>> > > > > > > > a
>> > > > mailing
>> > > > > > > > list (as is our old JIRA space), so if people want to
>> > participate
>> > > > > > > > without a GitHub account, they can still do that. There
>> > > > > > > > are
>> > certain
>> > > > > > > > options that are perhaps less convenient, such as just
>> > > > > > > > using
>> > the
>> > > > > > > > mailing list and our dev SVN space, but still more
>> > > > > > > > appropriate
>> > than
>> > > > > > > > options that would be less ubiquitous for potential
>> > participants.
>> > > > > > > >
>> > > > > > > > I think the ASF Confluence is probably fine, for storing,
>> > editing,
>> > > > and
>> > > > > > > > collaborating on shared documents, but decisions about
>> > > > > > > > those
>> > would
>> > > > > > > > still need to be done on the mailing list. If I remember
>> > > > correctly, we
>> > > > > > > > used to have a Wiki space, prior to it being transferred
>> > > > > > > > to Confluence, but it was poorly maintained, so we
>> > > > > > > > abandoned it in
>> > > > favor
>> > > > > > > > of using the website for docs. I could be mis-remembering,
>> > > > > > > > but
>> > I
>> > > > think
>> > > > > > > > this is the case. It might explain why you can't create a
>> > > > Confluence
>> > > > > > > > space.
>> > > > > > > >
>> > > > > > > > My preference would be to just use the website. I think
>> > > > > > > > it's
>> > fine
>> > > > to
>> > > > > > > > have a dev / design area of the website, and we can
>> > > > > > > > discuss on
>> > > > GitHub
>> > > > > > > > issues for the accumulo-website repo. That is a bit less
>> > convenient
>> > > > > > > > than Confluence if it's used heavily, but it's more
>> > > > > > > > convenient
>> > in
>> > > > the
>> > > > > > > > sense that it's more accessible and fits more in line with
>> > > > > > > > our
>> > > > current
>> > > > > > > > mode of operation. Plus, when a document is final, it's
>> > > > > > > > easy to
>> > > > link
>> > > > > > > > to from our documentation, without making users jump to
>> > > > > > > > another service to view docs.
>> > > > > > > >
>> > > > > > > > I would be opposed to using GitHub wiki or a new git repo.
>> > > > > > > > We
>> > have
>> > > > > > > > enough repos. Although it seems like they are free, there
>> > > > > > > > is
>> > still
>> > > > a
>> > > > > > > > lot of boilerplate work to maintain them, from managing
>> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
>> > .asf.yaml, to
>> > > > > > > > README, to keeping copyright dates updated in the NOTICE
>> > > > > > > > file,
>> > and
>> > > > > > > > more.
>> > > > > > > >
>> > > > > > > > In summary, my preference:
>> > > > > > > >
>> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH issues
>> > > > > > > > and
>> > > > mailing
>> > > > > > > > list (strongly preferred)
>> > > > > > > > 2. Confluence, discuss on mailing list (prefer over other
>> > options,
>> > > > but
>> > > > > > > > not a fan)
>> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly prefer
>> > > > > > > > not
>> > to use
>> > > > > > this
>> > > > > > > > option)
>> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing list
>> > (strongly
>> > > > > > > > prefer not to use this option)
>> > > > > > > >
>> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
>> > edcoleman@apache.org>
>> > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > Currently, asf cannot create new wiki's because of a
>> > Confluence
>> > > > > > issue (
>> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
>> > > > > > > > chatted
>> > with
>> > > > > > infra
>> > > > > > > > and in response they created that issue.
>> > > > > > > > >
>> > > > > > > > > To expand on this discussion, I would like to toss out
>> > another
>> > > > > > > > alternative to discuss / explore. What if we used a
>> > > > > > > > separate
>> > > > GitHub
>> > > > > > > > project, something like Accumulo-Design, just like
>> > accumulo-proxy
>> > > > and
>> > > > > > > > accumulo-examples. As a separate project, it would be
>> > available
>> > > > for
>> > > > > > > > collaboration for the community, but remain separate from
>> > > > > > > > main
>> > > > project
>> > > > > > and
>> > > > > > > > the website to keep current code / documentation / design
>> > clearly
>> > > > > > separate
>> > > > > > > > from speculative design discussions. As a project:
>> > > > > > > > >
>> > > > > > > > > - document history would be preserved with git commit
>> > history.
>> > > > > > > > > - document collaboration could be done with normal PR
>> > > > submissions /
>> > > > > > > > reviews.
>> > > > > > > > > - issues could be used to discuss design aspects,
>> > > > > > > > > capturing
>> > the
>> > > > > > comment
>> > > > > > > > history.
>> > > > > > > > >
>> > > > > > > > > The biggest downside is that it would be yet another
>> > > > > > > > > project
>> > to
>> > > > > > follow /
>> > > > > > > > track.
>> > > > > > > > >
>> > > > > > > > > For me, I think the issue is that we need a public,
>> > collaborative
>> > > > > > space
>> > > > > > > > to hold design discussions. Neither the main project or
>> > > > > > > > the
>> > > > web-site
>> > > > > > seem
>> > > > > > > > quite appropriate and Confluence seems to lack the
>> > collaboration
>> > > > that
>> > > > > > can
>> > > > > > > > be achieved with github.
>> > > > > > > > >
>> > > > > > > > > We need a space to capture the redesign and whatever we
>> > select
>> > > > can be
>> > > > > > > > made to work - I'm just wondering what provides the
>> > > > > > > > easiest
>> > forum
>> > > > to
>> > > > > > build
>> > > > > > > > a collaborative space for the Accumulo community.
>> > > > > > > > >
>> > > > > > > > > Ed Coleman
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
>> > > > > > > > > > Circling back on this issue - I agree that comments
>> > > > > > > > > > and
>> > such
>> > > > make
>> > > > > > > > sense for internal design documents. I'm going to create
>> > > > > > > > an
>> > INFRA
>> > > > > > ticket
>> > > > > > > > for a cwiki space for Accumulo unless there are any
>> objections.
>> > > > > > > > > >
>> > > > > > > > > > -----Original Message-----
>> > > > > > > > > > From: Drew Farris <dr...@ill.org>
>> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
>> > > > > > > > > > To: dev@accumulo.apache.org
>> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>> > > > > > > > > >
>> > > > > > > > > > As mentioned, wikis can provide a streamlined
>> > > > > > > > > > collaborative
>> > > > editing
>> > > > > > > > workflow that's less labor intensive than updating a
>> website.
>> > They
>> > > > can
>> > > > > > > > promote collaboration by providing specific tooling to
>> > > > > > > > support
>> > > > > > comments,
>> > > > > > > > revisions and iteration.
>> > > > > > > > > >
>> > > > > > > > > > In terms of preservation, GH wikis act just like any
>> > > > > > > > > > other
>> > Git
>> > > > > > > > repository, with a remote at (for example) git@github.com:
>> > > > > > > > apache/accumulo.wiki.git
>> > > > > > > > > > IIRC the pages are just GH flavored markdown. There
>> > > > > > > > > > are at
>> > > > least a
>> > > > > > few
>> > > > > > > > Apache projects using them.
>> > > > > > > > > >
>> > > > > > > > > > However, GH wikis lack some features that I feel are
>> > important
>> > > > to
>> > > > > > > > support collaborative authoring. For example, the ability
>> > > > > > > > to
>> > > > comment
>> > > > > > and
>> > > > > > > > discuss specific passages in a document is a feature
>> > > > > > > > that's
>> > > > present in
>> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate this this
>> > > > > > > > in
>> > my
>> > > > google
>> > > > > > > > docs and office workflows, so expect that it would be
>> > > > > > > > useful
>> > for
>> > > > > > Accumulo
>> > > > > > > > design discussions too.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
>> > > > kturner@apache.org>
>> > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > I would like to try a wiki for design documents, I
>> > > > > > > > > > > think
>> > it
>> > > > > > would be
>> > > > > > > > > > > less cumbersome than the website and we can always
>> > > > > > > > > > > link
>> > from
>> > > > the
>> > > > > > > > > > > website and issues to the wiki. I think its ok to
>> > > > > > > > > > > give
>> > it a
>> > > > try
>> > > > > > and
>> > > > > > > > > > > abandon it in the future, if abandoned would just
>> > > > > > > > > > > need to
>> > > > > > properly
>> > > > > > > > > > > communicate that. The content should be archived in
>> > Apache
>> > > > > > > > > > > infrastructure, so if GH wiki does not do that then
>> > > > > > > > > > > we
>> > should
>> > > > > > not use
>> > > > > > > > > > > it. If GH wiki is not an option then could try cwiki.
>> > > > > > > > > > >
>> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
>> > > > > > > > > > > <dl...@comcast.net>
>> > > > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > I reverted the change. I didn't think it would be
>> > > > > > > > > > > > a big
>> > > > deal,
>> > > > > > but
>> > > > > > > > if
>> > > > > > > > > > > > it
>> > > > > > > > > > > requires discussion, then let's discuss it.
>> > > > > > > > > > > >
>> > > > > > > > > > > > I'm looking for a place to host information
>> > > > > > > > > > > > related to
>> > > > internal
>> > > > > > > > > > > > design
>> > > > > > > > > > > discussions. I envision these to be living documents
>> > > > > > > > > > > that
>> > > > will be
>> > > > > > > > > > > updated over time as the design/implementation
>> > progresses and
>> > > > > > that
>> > > > > > > > > > > other committers will be able to comment on and
>> > > > > > > > > > > edit. I
>> > don't
>> > > > > > feel
>> > > > > > > > > > > that the website is the correct place for this
>> because:
>> > > > > > > > > > > >
>> > > > > > > > > > > > 1. I don't think internal design discussions
>> > > > > > > > > > > > should
>> > go
>> > > > on the
>> > > > > > > > > > > > project
>> > > > > > > > > > > website.
>> > > > > > > > > > > > 2. Changes to the design documents could not be
>> > > > > > > > > > > > seen
>> > by
>> > > > > > others
>> > > > > > > > > > > > right
>> > > > > > > > > > > away (IIRC changes to the website are built and
>> > available at
>> > > > > > > > > > > https://accumulo.staged.apache.org/, but human
>> > intervention
>> > > > is
>> > > > > > > > > > > required to publish it at
>> https://accumulo.apache.org/).
>> > > > > > > > > > > >
>> > > > > > > > > > > > I looked in the INFRA issues and other projects
>> > > > > > > > > > > > are
>> > using
>> > > > the
>> > > > > > GH
>> > > > > > > > > > > > Wiki
>> > > > > > > > > > > feature and I saw no mention of backing it up or the
>> > > > requirement
>> > > > > > to
>> > > > > > > > do
>> > > > > > > > > > > so (maybe they rely on GitHub backing it up?). It
>> > > > > > > > > > > does
>> > appear
>> > > > > > that we
>> > > > > > > > > > > would need an INFRA ticket so that they can modify
>> > > > > > > > > > > the
>> > GitHub
>> > > > > > project
>> > > > > > > > > > > settings to lock the GitHub wiki down so that only
>> > > > committers can
>> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then I
>> > > > > > > > > > > think
>> > > > Apache
>> > > > > > > > > > > Confluence (
>> > > > > > > > > > > https://cwiki.apache.org) might be an acceptable
>> > > > alternative.
>> > > > > > > > > > > >
>> > > > > > > > > > > > -----Original Message-----
>> > > > > > > > > > > > From: Christopher <ct...@apache.org>
>> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
>> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
>> > > > > > > > > > > > Cc: commits@accumulo.apache.org
>> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
>> > > > > > > > > > > > Enable
>> > Github
>> > > > > > wiki in
>> > > > > > > > > > > asf.yaml
>> > > > > > > > > > > >
>> > > > > > > > > > > > I don't recall a discussion about this change, but
>> > > > > > > > > > > > I
>> > think
>> > > > it
>> > > > > > goes
>> > > > > > > > > > > against previous efforts to make the website the one
>> > > > canonical
>> > > > > > > > > > > location for our documentation. I don't even think
>> > > > > > > > > > > infra
>> > is
>> > > > > > backing
>> > > > > > > > up
>> > > > > > > > > > > wiki repos, so there wouldn't even be a record of
>> > > > > > > > > > > the
>> > wiki
>> > > > > > contents
>> > > > > > > > in
>> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed up to
>> > GitBox
>> > > > and
>> > > > > > the
>> > > > > > > > > > > issue tracker, which CCs the notifications list).
>> > > > > > > > > > > >
>> > > > > > > > > > > > In short, I think this should be reverted and we
>> > should not
>> > > > > > use the
>> > > > > > > > > > > GitHub wiki. If we need to store documents in a
>> > > > > > > > > > > version
>> > > > > > controlled
>> > > > > > > > > > > way, we can store them on the website, or in our
>> > project's
>> > > > SVN
>> > > > > > dev
>> > > > > > > > > > > space. The wiki is just another place people would
>> > > > > > > > > > > have
>> > to
>> > > > > > follow if
>> > > > > > > > > > > they want to participate, and I don't think that
>> > > > > > > > > > > serves
>> > us.
>> > > > > > > > Therefore,
>> > > > > > > > > > > I think we shouldn't use it.
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org>
>> > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > > This is an automated email from the ASF
>> > > > > > > > > > > > > dual-hosted
>> > git
>> > > > > > > > repository.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
>> > > > > > > > > > > > > repository
>> > > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > The following commit(s) were added to
>> > refs/heads/main by
>> > > > this
>> > > > > > > > push:
>> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
>> > > > > > > > > > > > > asf.yaml
>> > > > > > ae8a817e7b is
>> > > > > > > > > > > > > described below
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
>> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
>> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Enable Github wiki in asf.yaml
>> > > > > > > > > > > > > ---
>> > > > > > > > > > > > > .asf.yaml | 2 +-
>> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
>> > > > > > bc2c943e82..08aa357082
>> > > > > > > > > > > > > 100644
>> > > > > > > > > > > > > --- a/.asf.yaml
>> > > > > > > > > > > > > +++ b/.asf.yaml
>> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
>> > > > > > > > > > > > > - big-data
>> > > > > > > > > > > > > - hacktoberfest
>> > > > > > > > > > > > > features:
>> > > > > > > > > > > > > - wiki: false
>> > > > > > > > > > > > > + wiki: true
>> > > > > > > > > > > > > issues: true
>> > > > > > > > > > > > > projects: true
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > >
>> >
>>
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
https://issues.apache.org/jira/browse/INFRA-24291 is still unresolved and
the only comment on the ticket is one that Ed added two days ago requesting
an ACCUMULO wiki space.
On Fri, Mar 3, 2023 at 12:26 PM dev1 <de...@etcoleman.com> wrote:
> I do not see any comments in the infa slack channel - so no updates for
> now.
>
> -----Original Message-----
> From: Dave Marion <dm...@gmail.com>
> Sent: Friday, March 3, 2023 12:06 PM
> To: dev@accumulo.apache.org
> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>
> Right, I was just curious if there was any follow-up as I think Ed said
> that it was going to be discussed by the INFRA team yesterday. There is at
> least one other recent ticket (
> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve had an
> issue and the INFRA team created the space manually.
>
> On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org> wrote:
>
> > You can track that issue at
> > https://issues.apache.org/jira/browse/INFRA-24291
> >
> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com> wrote:
> > >
> > > Ed,
> > >
> > > Any update from INFRA on being able to create confluence pages?
> > >
> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org>
> wrote:
> > >
> > > > We've definitely used the website for more than that. We use it to
> > > > document things for users, help developers know how to contribute,
> > > > store drafts of designs, share user stories via blogs, do release
> > > > announcements, and more. There's definitely space on the website
> > > > to do this kind of thing, if we want to. We've used it that way
> > > > before. If you only see it as a place "for user consumption after
> > > > everything has been finalized", then you're missing out on the
> > > > other ways we currently use the site, and the ways we've used it in
> the past.
> > > >
> > > > With the website, most of the collaboration would happen in the GH
> > > > issues about proposed designs or changes to designs, just like we
> > > > do today with code or other documentation, which everybody is used
> > > > to. I agree it's not as good as Google Docs for on-the-fly
> > > > comments/annotations, but I don't think Confluence or Wiki are as
> > > > good as that either, and Google Docs isn't really an option...
> > > > unless you just want to link to it in the mailing list and stick
> > > > to Google Docs from your personal Google account, until it's ready
> > > > for publication, which would also be fine (any interested persons
> > > > can simply request write access by replying to the message where you
> shared the link)..
> > > >
> > > > We are a much smaller project than many others, and we have
> > > > previously suffered from having stuff too spread out. Even if
> > > > other projects find a separate space valuable for them, I'm not
> > > > sure it's best for the Accumulo project. While I think it's useful
> > > > to examine what other projects do, I do think we should be careful
> > > > to adopt anything just because others find it convenient for them.
> > > >
> > > > Confluence is my second choice, but with a big gap between it and
> > > > my first choice.
> > > >
> > > > On a personal note: I hate using Confluence, because I think the
> > > > navigation is highly unintuitive, as is the permissions model, and
> > > > I don't like the idea of learning yet another wiki-syntax (though
> > > > I've read Confluence supports some limited Markdown, but probably
> > > > not the same as GitHub/Jekyll). I also do not want to set up
> > > > custom notifications for watching yet another space. If we use
> > > > Confluence, I will probably contribute very infrequently there
> > > > because of my frustrations with having used it before. However,
> > > > that would be my choice, and should not be a reason the project
> > > > chooses one over another. I'm sharing my personal opinion only
> > > > because it is influencing my opinion about the website being more
> > > > accessible, via our current GitHub PR/issue/Markdown workflows,
> > > > and I wonder how many other potential contributors would feel
> > > > similarly. It's hard to know, since it seems like a lot of this is
> > > > subjective, and is going to come down to a consensus of personal
> preferences.
> > > >
> > > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com>
> > wrote:
> > > > >
> > > > > I don't see the website as an area where we would have
> > > > > collaborative discussions about an idea. For example, making
> > > > > comments and
> > suggestions
> > > > on
> > > > > a document like you can do in Google Docs. I see the website as
> > > > > a
> > place
> > > > > where items are documented for user consumption after everything
> > > > > has
> > been
> > > > > finalized. I'm not trying to create a private discussion area, I
> > think
> > > > > anyone can see the wiki (but I think anonymous comments are
> > > > > disabled
> > due
> > > > to
> > > > > spam issues). I see no issue with putting work-in-progress
> > > > > documents
> > on a
> > > > > wiki and referencing them via emails to the dev list. I think
> > > > > this is
> > > > done
> > > > > in a lot of other projects. Non-committers that don't have
> > > > > access to
> > the
> > > > > wiki and want to make comments, suggestions, and ask questions
> > > > > can
> > do so
> > > > > via the mailing list. I think it's also possible that people can
> > > > > get confluence accounts (see
> > > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > > so if a non-committer wanted to participate they could.
> > > > >
> > > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org>
> > wrote:
> > > > >
> > > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > > <dm...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > I'm opposed to using the website for the reasons I specified
> > > > earlier, so
> > > > > > it
> > > > > >
> > > > > > Your reasons that I saw were:
> > > > > >
> > > > > > > 1. I don't think internal design discussions should go on
> > > > > > > the
> > project
> > > > > > website.
> > > > > >
> > > > > > That doesn't look to me like a reason. That appears to just be
> > stating
> > > > > > the conclusion. Did I miss your reason here?
> > > > > >
> > > > > > > 2. Changes to the design documents could not be seen by
> > > > > > > others
> > right
> > > > > > away (IIRC changes to the website are built and available at
> > > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > required
> > > > > > to publish it at https://accumulo.apache.org/).
> > > > > >
> > > > > > What do you mean by "others" here? Do you mean "users", as
> > > > > > opposed
> > to
> > > > > > "developers/contributors"? The ASF draws a distinction between
> > > > > > "developers/contributors" and "users" as it pertains to
> > > > > > official releases. Releases are intended to be consumed by
> > > > > > users, and pre-release stuff is intended to be collaborative,
> > > > > > open to all potential developers/contributors. Very very
> > > > > > rarely are things reserved exclusively for committers. We
> > > > > > don't even have a private committers space (the private
> > > > > > mailing list is PMC-private, not committer-private). Having a
> > > > > > distinction between users and
> > developers
> > > > > > doesn't mean we can't publish things on the website... it just
> > means
> > > > > > that we should be careful about how we do it, which is the
> > > > > > same
> > care
> > > > > > we should take regardless of where we put it. Specifically,
> > > > > > the
> > care
> > > > > > we need to take is to avoid marketing pre-release content to
> users.
> > > > > > One way we can exercise this care for content on our website
> > > > > > is
> > that
> > > > > > we can avoid sharing these unpolished designs by simply not
> > > > > > linking them on the site, or by placing them in an area that
> > > > > > is clearly
> > marked
> > > > > > as intended for devs. But, we have no similar distinction
> > > > > > between committers and non-committer devs for which we should
> > > > > > avoid sharing pre-release content under development. In fact,
> > > > > > it is the
> > opposite...
> > > > > > we should be developing openly so as to allow room for
> > non-committers
> > > > > > to become committers through participation in development
> > activities.
> > > > > >
> > > > > > As for the staging/publication of the website, that's just a
> > mechanic
> > > > > > for verifying the website isn't broken before we serve it.
> > > > > > It's
> > not a
> > > > > > mechanism for keeping things internal vs. shared and doesn't
> > > > > > have anything to do with the separation between devs and
> > > > > > users. We
> > already
> > > > > > publish Draft contents to the website, as well as
> > developer-specific
> > > > > > documentation not intended for users.
> > > > > >
> > > > > > We've even specifically published work-in-progress design
> > > > > > documents there, of the same type that seems to be the basis
> > > > > > of this conversation (
> https://accumulo.apache.org/design/system-snapshot).
> > I
> > > > > > would strongly prefer us to continue to do it this way, rather
> > > > > > than create a new space, and have these kinds of things
> > > > > > scattered in multiple places.
> > > > > >
> > > > > > If, on the other hand, you intend to say that these should be
> > private
> > > > > > because they aren't ready for other potential contributors,
> > > > > > then I would argue that we're an openly developed project...
> > > > > > if something isn't ready to be shared with other potential
> > > > > > contributors / developers, such that you want to keep it
> > > > > > internal to existing committers, then it's not ready to be
> > > > > > contributed to the project at all... because we don't restrict
> > > > > > collaboration to only existing committers. That would prevent
> > > > > > others from participating and
> > earning
> > > > > > the merit to become committers, and that's not something we
> > > > > > should
> > be
> > > > > > doing. Anything that is okay to share with existing committers
> > should
> > > > > > be okay to share to other potential contributors who want to
> > > > > > participate, and should be done in a space that allows them to
> > > > > > do that. The website is a perfect space for that, and has
> > > > > > everything
> > we
> > > > > > need. I'm actually not sure about Confluence... I suspect
> > > > > > non-committers wouldn't be able to participate there because
> > > > > > they probably can't get accounts for it.
> > > > > >
> > > > > >
> > > > > > > looks like we need to
> > > > > > > wait for INFRA to fix Confluence. I'd be curious how much we
> > need to
> > > > use
> > > > > > > the mailing list during
> > > > > > > the design phase. We can announce meeting dates/times on the
> > mailing
> > > > list
> > > > > > > and post links to
> > > > > > > meeting notes in Confluence. Ultimately, decisions made by
> > > > > > > the
> > people
> > > > > > that
> > > > > > > want to be involved
> > > > > > > will turn into pull requests against the codebase which
> > comitters can
> > > > > > weigh
> > > > > > > in on. When you say,
> > > > > > > "... but decisions about those would still need to be done
> > > > > > > on the
> > > > mailing
> > > > > > > list." Are you saying that
> > > > > > > we need to discuss every single design decision on the
> > > > > > > mailing
> > list?
> > > > > >
> > > > > > Yes and no. I am saying that decisions need to happen on the
> > mailing
> > > > > > list, but I agree with you that this can be satisfied through
> > > > > > pull requests. I just wanted to emphasize that regardless of
> > > > > > where we do that pre-decision collaboration, that
> > > > > > collaboration should not be misconstrued as a decision to accept
> those ideas into the project.
> > The
> > > > > > decision occurs during the PR or other activity that
> > > > > > interfaces
> > with
> > > > > > the mailing list, subsequent to the collaboration in the
> > design/idea
> > > > > > phase.
> > > > > >
> > > > > > As for the pre-decision collaboration space we're discussing,
> > > > > > I
> > just
> > > > > > want to be careful that we're not creating such a space in an
> > > > > > exclusionary way that allows only existing committers to
> > participate,
> > > > > > that excludes other potential contributors. This is still an
> > > > > > openly-developed project, and we should collaborate in a space
> > that is
> > > > > > not exclusive to existing committers, but open to
> > > > > > non-committer contributors and potential contributors as well.
> > > > > > So, while we may
> > want
> > > > > > to keep a line separating dev activity from user consumption
> > > > > > (an important separation that relates to official ASF
> > > > > > releases), we
> > should
> > > > > > not be drawing a line between committer-devs as "internal" and
> > > > > > contributor-devs as "external". The website, with its own
> > > > > > issue tracker, the ability to render markdown, do reviews, and
> > > > > > collaboratively edit, seems like the ideal place to me. We've
> > > > > > used
> > it
> > > > > > before for the same purpose, and I think we should continue to
> > > > > > do
> > so.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > > <ctubbsii@apache.org
> > >
> > > > wrote:
> > > > > > >
> > > > > > > > So, I agree a space would be helpful. Although it's old
> > > > > > > > school
> > and
> > > > > > > > inconvenient, the mailing list is the canonical place for
> > > > discussion.
> > > > > > > > We currently use GitHub issues a lot, but that's copied to
> > > > > > > > a
> > > > mailing
> > > > > > > > list (as is our old JIRA space), so if people want to
> > participate
> > > > > > > > without a GitHub account, they can still do that. There
> > > > > > > > are
> > certain
> > > > > > > > options that are perhaps less convenient, such as just
> > > > > > > > using
> > the
> > > > > > > > mailing list and our dev SVN space, but still more
> > > > > > > > appropriate
> > than
> > > > > > > > options that would be less ubiquitous for potential
> > participants.
> > > > > > > >
> > > > > > > > I think the ASF Confluence is probably fine, for storing,
> > editing,
> > > > and
> > > > > > > > collaborating on shared documents, but decisions about
> > > > > > > > those
> > would
> > > > > > > > still need to be done on the mailing list. If I remember
> > > > correctly, we
> > > > > > > > used to have a Wiki space, prior to it being transferred
> > > > > > > > to Confluence, but it was poorly maintained, so we
> > > > > > > > abandoned it in
> > > > favor
> > > > > > > > of using the website for docs. I could be mis-remembering,
> > > > > > > > but
> > I
> > > > think
> > > > > > > > this is the case. It might explain why you can't create a
> > > > Confluence
> > > > > > > > space.
> > > > > > > >
> > > > > > > > My preference would be to just use the website. I think
> > > > > > > > it's
> > fine
> > > > to
> > > > > > > > have a dev / design area of the website, and we can
> > > > > > > > discuss on
> > > > GitHub
> > > > > > > > issues for the accumulo-website repo. That is a bit less
> > convenient
> > > > > > > > than Confluence if it's used heavily, but it's more
> > > > > > > > convenient
> > in
> > > > the
> > > > > > > > sense that it's more accessible and fits more in line with
> > > > > > > > our
> > > > current
> > > > > > > > mode of operation. Plus, when a document is final, it's
> > > > > > > > easy to
> > > > link
> > > > > > > > to from our documentation, without making users jump to
> > > > > > > > another service to view docs.
> > > > > > > >
> > > > > > > > I would be opposed to using GitHub wiki or a new git repo.
> > > > > > > > We
> > have
> > > > > > > > enough repos. Although it seems like they are free, there
> > > > > > > > is
> > still
> > > > a
> > > > > > > > lot of boilerplate work to maintain them, from managing
> > > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> > .asf.yaml, to
> > > > > > > > README, to keeping copyright dates updated in the NOTICE
> > > > > > > > file,
> > and
> > > > > > > > more.
> > > > > > > >
> > > > > > > > In summary, my preference:
> > > > > > > >
> > > > > > > > 1. Keep a space in accumulo-website, discuss on GH issues
> > > > > > > > and
> > > > mailing
> > > > > > > > list (strongly preferred)
> > > > > > > > 2. Confluence, discuss on mailing list (prefer over other
> > options,
> > > > but
> > > > > > > > not a fan)
> > > > > > > > 3. GitHub wiki, discuss on mailing list (strongly prefer
> > > > > > > > not
> > to use
> > > > > > this
> > > > > > > > option)
> > > > > > > > 4. New GitHub repo, discuss on GH issues and mailing list
> > (strongly
> > > > > > > > prefer not to use this option)
> > > > > > > >
> > > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> > edcoleman@apache.org>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Currently, asf cannot create new wiki's because of a
> > Confluence
> > > > > > issue (
> > > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
> > > > > > > > chatted
> > with
> > > > > > infra
> > > > > > > > and in response they created that issue.
> > > > > > > > >
> > > > > > > > > To expand on this discussion, I would like to toss out
> > another
> > > > > > > > alternative to discuss / explore. What if we used a
> > > > > > > > separate
> > > > GitHub
> > > > > > > > project, something like Accumulo-Design, just like
> > accumulo-proxy
> > > > and
> > > > > > > > accumulo-examples. As a separate project, it would be
> > available
> > > > for
> > > > > > > > collaboration for the community, but remain separate from
> > > > > > > > main
> > > > project
> > > > > > and
> > > > > > > > the website to keep current code / documentation / design
> > clearly
> > > > > > separate
> > > > > > > > from speculative design discussions. As a project:
> > > > > > > > >
> > > > > > > > > - document history would be preserved with git commit
> > history.
> > > > > > > > > - document collaboration could be done with normal PR
> > > > submissions /
> > > > > > > > reviews.
> > > > > > > > > - issues could be used to discuss design aspects,
> > > > > > > > > capturing
> > the
> > > > > > comment
> > > > > > > > history.
> > > > > > > > >
> > > > > > > > > The biggest downside is that it would be yet another
> > > > > > > > > project
> > to
> > > > > > follow /
> > > > > > > > track.
> > > > > > > > >
> > > > > > > > > For me, I think the issue is that we need a public,
> > collaborative
> > > > > > space
> > > > > > > > to hold design discussions. Neither the main project or
> > > > > > > > the
> > > > web-site
> > > > > > seem
> > > > > > > > quite appropriate and Confluence seems to lack the
> > collaboration
> > > > that
> > > > > > can
> > > > > > > > be achieved with github.
> > > > > > > > >
> > > > > > > > > We need a space to capture the redesign and whatever we
> > select
> > > > can be
> > > > > > > > made to work - I'm just wondering what provides the
> > > > > > > > easiest
> > forum
> > > > to
> > > > > > build
> > > > > > > > a collaborative space for the Accumulo community.
> > > > > > > > >
> > > > > > > > > Ed Coleman
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > > > > > Circling back on this issue - I agree that comments
> > > > > > > > > > and
> > such
> > > > make
> > > > > > > > sense for internal design documents. I'm going to create
> > > > > > > > an
> > INFRA
> > > > > > ticket
> > > > > > > > for a cwiki space for Accumulo unless there are any
> objections.
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > > >
> > > > > > > > > > As mentioned, wikis can provide a streamlined
> > > > > > > > > > collaborative
> > > > editing
> > > > > > > > workflow that's less labor intensive than updating a website.
> > They
> > > > can
> > > > > > > > promote collaboration by providing specific tooling to
> > > > > > > > support
> > > > > > comments,
> > > > > > > > revisions and iteration.
> > > > > > > > > >
> > > > > > > > > > In terms of preservation, GH wikis act just like any
> > > > > > > > > > other
> > Git
> > > > > > > > repository, with a remote at (for example) git@github.com:
> > > > > > > > apache/accumulo.wiki.git
> > > > > > > > > > IIRC the pages are just GH flavored markdown. There
> > > > > > > > > > are at
> > > > least a
> > > > > > few
> > > > > > > > Apache projects using them.
> > > > > > > > > >
> > > > > > > > > > However, GH wikis lack some features that I feel are
> > important
> > > > to
> > > > > > > > support collaborative authoring. For example, the ability
> > > > > > > > to
> > > > comment
> > > > > > and
> > > > > > > > discuss specific passages in a document is a feature
> > > > > > > > that's
> > > > present in
> > > > > > > > Cwiki, but not in GH wikis. I've come appreciate this this
> > > > > > > > in
> > my
> > > > google
> > > > > > > > docs and office workflows, so expect that it would be
> > > > > > > > useful
> > for
> > > > > > Accumulo
> > > > > > > > design discussions too.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > > kturner@apache.org>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I would like to try a wiki for design documents, I
> > > > > > > > > > > think
> > it
> > > > > > would be
> > > > > > > > > > > less cumbersome than the website and we can always
> > > > > > > > > > > link
> > from
> > > > the
> > > > > > > > > > > website and issues to the wiki. I think its ok to
> > > > > > > > > > > give
> > it a
> > > > try
> > > > > > and
> > > > > > > > > > > abandon it in the future, if abandoned would just
> > > > > > > > > > > need to
> > > > > > properly
> > > > > > > > > > > communicate that. The content should be archived in
> > Apache
> > > > > > > > > > > infrastructure, so if GH wiki does not do that then
> > > > > > > > > > > we
> > should
> > > > > > not use
> > > > > > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > > > > > > <dl...@comcast.net>
> > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > I reverted the change. I didn't think it would be
> > > > > > > > > > > > a big
> > > > deal,
> > > > > > but
> > > > > > > > if
> > > > > > > > > > > > it
> > > > > > > > > > > requires discussion, then let's discuss it.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm looking for a place to host information
> > > > > > > > > > > > related to
> > > > internal
> > > > > > > > > > > > design
> > > > > > > > > > > discussions. I envision these to be living documents
> > > > > > > > > > > that
> > > > will be
> > > > > > > > > > > updated over time as the design/implementation
> > progresses and
> > > > > > that
> > > > > > > > > > > other committers will be able to comment on and
> > > > > > > > > > > edit. I
> > don't
> > > > > > feel
> > > > > > > > > > > that the website is the correct place for this because:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. I don't think internal design discussions
> > > > > > > > > > > > should
> > go
> > > > on the
> > > > > > > > > > > > project
> > > > > > > > > > > website.
> > > > > > > > > > > > 2. Changes to the design documents could not be
> > > > > > > > > > > > seen
> > by
> > > > > > others
> > > > > > > > > > > > right
> > > > > > > > > > > away (IIRC changes to the website are built and
> > available at
> > > > > > > > > > > https://accumulo.staged.apache.org/, but human
> > intervention
> > > > is
> > > > > > > > > > > required to publish it at https://accumulo.apache.org/
> ).
> > > > > > > > > > > >
> > > > > > > > > > > > I looked in the INFRA issues and other projects
> > > > > > > > > > > > are
> > using
> > > > the
> > > > > > GH
> > > > > > > > > > > > Wiki
> > > > > > > > > > > feature and I saw no mention of backing it up or the
> > > > requirement
> > > > > > to
> > > > > > > > do
> > > > > > > > > > > so (maybe they rely on GitHub backing it up?). It
> > > > > > > > > > > does
> > appear
> > > > > > that we
> > > > > > > > > > > would need an INFRA ticket so that they can modify
> > > > > > > > > > > the
> > GitHub
> > > > > > project
> > > > > > > > > > > settings to lock the GitHub wiki down so that only
> > > > committers can
> > > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then I
> > > > > > > > > > > think
> > > > Apache
> > > > > > > > > > > Confluence (
> > > > > > > > > > > https://cwiki.apache.org) might be an acceptable
> > > > alternative.
> > > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> > > > > > > > > > > > Enable
> > Github
> > > > > > wiki in
> > > > > > > > > > > asf.yaml
> > > > > > > > > > > >
> > > > > > > > > > > > I don't recall a discussion about this change, but
> > > > > > > > > > > > I
> > think
> > > > it
> > > > > > goes
> > > > > > > > > > > against previous efforts to make the website the one
> > > > canonical
> > > > > > > > > > > location for our documentation. I don't even think
> > > > > > > > > > > infra
> > is
> > > > > > backing
> > > > > > > > up
> > > > > > > > > > > wiki repos, so there wouldn't even be a record of
> > > > > > > > > > > the
> > wiki
> > > > > > contents
> > > > > > > > in
> > > > > > > > > > > ASF spaces (vs. the main repo, which is backed up to
> > GitBox
> > > > and
> > > > > > the
> > > > > > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > > > > > >
> > > > > > > > > > > > In short, I think this should be reverted and we
> > should not
> > > > > > use the
> > > > > > > > > > > GitHub wiki. If we need to store documents in a
> > > > > > > > > > > version
> > > > > > controlled
> > > > > > > > > > > way, we can store them on the website, or in our
> > project's
> > > > SVN
> > > > > > dev
> > > > > > > > > > > space. The wiki is just another place people would
> > > > > > > > > > > have
> > to
> > > > > > follow if
> > > > > > > > > > > they want to participate, and I don't think that
> > > > > > > > > > > serves
> > us.
> > > > > > > > Therefore,
> > > > > > > > > > > I think we shouldn't use it.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org>
> > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > This is an automated email from the ASF
> > > > > > > > > > > > > dual-hosted
> > git
> > > > > > > > repository.
> > > > > > > > > > > > >
> > > > > > > > > > > > > dlmarion pushed a commit to branch main in
> > > > > > > > > > > > > repository
> > > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The following commit(s) were added to
> > refs/heads/main by
> > > > this
> > > > > > > > push:
> > > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> > > > > > > > > > > > > asf.yaml
> > > > > > ae8a817e7b is
> > > > > > > > > > > > > described below
> > > > > > > > > > > > >
> > > > > > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > > > > > >
> > > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > > > bc2c943e82..08aa357082
> > > > > > > > > > > > > 100644
> > > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > > > > > - big-data
> > > > > > > > > > > > > - hacktoberfest
> > > > > > > > > > > > > features:
> > > > > > > > > > > > > - wiki: false
> > > > > > > > > > > > > + wiki: true
> > > > > > > > > > > > > issues: true
> > > > > > > > > > > > > projects: true
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
RE: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by dev1 <de...@etcoleman.com>.
I do not see any comments in the infa slack channel - so no updates for now.
-----Original Message-----
From: Dave Marion <dm...@gmail.com>
Sent: Friday, March 3, 2023 12:06 PM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
Right, I was just curious if there was any follow-up as I think Ed said that it was going to be discussed by the INFRA team yesterday. There is at least one other recent ticket (
https://issues.apache.org/jira/browse/INFRA-24216) where selfserve had an issue and the INFRA team created the space manually.
On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org> wrote:
> You can track that issue at
> https://issues.apache.org/jira/browse/INFRA-24291
>
> On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com> wrote:
> >
> > Ed,
> >
> > Any update from INFRA on being able to create confluence pages?
> >
> > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org> wrote:
> >
> > > We've definitely used the website for more than that. We use it to
> > > document things for users, help developers know how to contribute,
> > > store drafts of designs, share user stories via blogs, do release
> > > announcements, and more. There's definitely space on the website
> > > to do this kind of thing, if we want to. We've used it that way
> > > before. If you only see it as a place "for user consumption after
> > > everything has been finalized", then you're missing out on the
> > > other ways we currently use the site, and the ways we've used it in the past.
> > >
> > > With the website, most of the collaboration would happen in the GH
> > > issues about proposed designs or changes to designs, just like we
> > > do today with code or other documentation, which everybody is used
> > > to. I agree it's not as good as Google Docs for on-the-fly
> > > comments/annotations, but I don't think Confluence or Wiki are as
> > > good as that either, and Google Docs isn't really an option...
> > > unless you just want to link to it in the mailing list and stick
> > > to Google Docs from your personal Google account, until it's ready
> > > for publication, which would also be fine (any interested persons
> > > can simply request write access by replying to the message where you shared the link)..
> > >
> > > We are a much smaller project than many others, and we have
> > > previously suffered from having stuff too spread out. Even if
> > > other projects find a separate space valuable for them, I'm not
> > > sure it's best for the Accumulo project. While I think it's useful
> > > to examine what other projects do, I do think we should be careful
> > > to adopt anything just because others find it convenient for them.
> > >
> > > Confluence is my second choice, but with a big gap between it and
> > > my first choice.
> > >
> > > On a personal note: I hate using Confluence, because I think the
> > > navigation is highly unintuitive, as is the permissions model, and
> > > I don't like the idea of learning yet another wiki-syntax (though
> > > I've read Confluence supports some limited Markdown, but probably
> > > not the same as GitHub/Jekyll). I also do not want to set up
> > > custom notifications for watching yet another space. If we use
> > > Confluence, I will probably contribute very infrequently there
> > > because of my frustrations with having used it before. However,
> > > that would be my choice, and should not be a reason the project
> > > chooses one over another. I'm sharing my personal opinion only
> > > because it is influencing my opinion about the website being more
> > > accessible, via our current GitHub PR/issue/Markdown workflows,
> > > and I wonder how many other potential contributors would feel
> > > similarly. It's hard to know, since it seems like a lot of this is
> > > subjective, and is going to come down to a consensus of personal preferences.
> > >
> > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com>
> wrote:
> > > >
> > > > I don't see the website as an area where we would have
> > > > collaborative discussions about an idea. For example, making
> > > > comments and
> suggestions
> > > on
> > > > a document like you can do in Google Docs. I see the website as
> > > > a
> place
> > > > where items are documented for user consumption after everything
> > > > has
> been
> > > > finalized. I'm not trying to create a private discussion area, I
> think
> > > > anyone can see the wiki (but I think anonymous comments are
> > > > disabled
> due
> > > to
> > > > spam issues). I see no issue with putting work-in-progress
> > > > documents
> on a
> > > > wiki and referencing them via emails to the dev list. I think
> > > > this is
> > > done
> > > > in a lot of other projects. Non-committers that don't have
> > > > access to
> the
> > > > wiki and want to make comments, suggestions, and ask questions
> > > > can
> do so
> > > > via the mailing list. I think it's also possible that people can
> > > > get confluence accounts (see
> > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > so if a non-committer wanted to participate they could.
> > > >
> > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org>
> wrote:
> > > >
> > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion
> > > > > <dm...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > I'm opposed to using the website for the reasons I specified
> > > earlier, so
> > > > > it
> > > > >
> > > > > Your reasons that I saw were:
> > > > >
> > > > > > 1. I don't think internal design discussions should go on
> > > > > > the
> project
> > > > > website.
> > > > >
> > > > > That doesn't look to me like a reason. That appears to just be
> stating
> > > > > the conclusion. Did I miss your reason here?
> > > > >
> > > > > > 2. Changes to the design documents could not be seen by
> > > > > > others
> right
> > > > > away (IIRC changes to the website are built and available at
> > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > required
> > > > > to publish it at https://accumulo.apache.org/).
> > > > >
> > > > > What do you mean by "others" here? Do you mean "users", as
> > > > > opposed
> to
> > > > > "developers/contributors"? The ASF draws a distinction between
> > > > > "developers/contributors" and "users" as it pertains to
> > > > > official releases. Releases are intended to be consumed by
> > > > > users, and pre-release stuff is intended to be collaborative,
> > > > > open to all potential developers/contributors. Very very
> > > > > rarely are things reserved exclusively for committers. We
> > > > > don't even have a private committers space (the private
> > > > > mailing list is PMC-private, not committer-private). Having a
> > > > > distinction between users and
> developers
> > > > > doesn't mean we can't publish things on the website... it just
> means
> > > > > that we should be careful about how we do it, which is the
> > > > > same
> care
> > > > > we should take regardless of where we put it. Specifically,
> > > > > the
> care
> > > > > we need to take is to avoid marketing pre-release content to users.
> > > > > One way we can exercise this care for content on our website
> > > > > is
> that
> > > > > we can avoid sharing these unpolished designs by simply not
> > > > > linking them on the site, or by placing them in an area that
> > > > > is clearly
> marked
> > > > > as intended for devs. But, we have no similar distinction
> > > > > between committers and non-committer devs for which we should
> > > > > avoid sharing pre-release content under development. In fact,
> > > > > it is the
> opposite...
> > > > > we should be developing openly so as to allow room for
> non-committers
> > > > > to become committers through participation in development
> activities.
> > > > >
> > > > > As for the staging/publication of the website, that's just a
> mechanic
> > > > > for verifying the website isn't broken before we serve it.
> > > > > It's
> not a
> > > > > mechanism for keeping things internal vs. shared and doesn't
> > > > > have anything to do with the separation between devs and
> > > > > users. We
> already
> > > > > publish Draft contents to the website, as well as
> developer-specific
> > > > > documentation not intended for users.
> > > > >
> > > > > We've even specifically published work-in-progress design
> > > > > documents there, of the same type that seems to be the basis
> > > > > of this conversation (https://accumulo.apache.org/design/system-snapshot).
> I
> > > > > would strongly prefer us to continue to do it this way, rather
> > > > > than create a new space, and have these kinds of things
> > > > > scattered in multiple places.
> > > > >
> > > > > If, on the other hand, you intend to say that these should be
> private
> > > > > because they aren't ready for other potential contributors,
> > > > > then I would argue that we're an openly developed project...
> > > > > if something isn't ready to be shared with other potential
> > > > > contributors / developers, such that you want to keep it
> > > > > internal to existing committers, then it's not ready to be
> > > > > contributed to the project at all... because we don't restrict
> > > > > collaboration to only existing committers. That would prevent
> > > > > others from participating and
> earning
> > > > > the merit to become committers, and that's not something we
> > > > > should
> be
> > > > > doing. Anything that is okay to share with existing committers
> should
> > > > > be okay to share to other potential contributors who want to
> > > > > participate, and should be done in a space that allows them to
> > > > > do that. The website is a perfect space for that, and has
> > > > > everything
> we
> > > > > need. I'm actually not sure about Confluence... I suspect
> > > > > non-committers wouldn't be able to participate there because
> > > > > they probably can't get accounts for it.
> > > > >
> > > > >
> > > > > > looks like we need to
> > > > > > wait for INFRA to fix Confluence. I'd be curious how much we
> need to
> > > use
> > > > > > the mailing list during
> > > > > > the design phase. We can announce meeting dates/times on the
> mailing
> > > list
> > > > > > and post links to
> > > > > > meeting notes in Confluence. Ultimately, decisions made by
> > > > > > the
> people
> > > > > that
> > > > > > want to be involved
> > > > > > will turn into pull requests against the codebase which
> comitters can
> > > > > weigh
> > > > > > in on. When you say,
> > > > > > "... but decisions about those would still need to be done
> > > > > > on the
> > > mailing
> > > > > > list." Are you saying that
> > > > > > we need to discuss every single design decision on the
> > > > > > mailing
> list?
> > > > >
> > > > > Yes and no. I am saying that decisions need to happen on the
> mailing
> > > > > list, but I agree with you that this can be satisfied through
> > > > > pull requests. I just wanted to emphasize that regardless of
> > > > > where we do that pre-decision collaboration, that
> > > > > collaboration should not be misconstrued as a decision to accept those ideas into the project.
> The
> > > > > decision occurs during the PR or other activity that
> > > > > interfaces
> with
> > > > > the mailing list, subsequent to the collaboration in the
> design/idea
> > > > > phase.
> > > > >
> > > > > As for the pre-decision collaboration space we're discussing,
> > > > > I
> just
> > > > > want to be careful that we're not creating such a space in an
> > > > > exclusionary way that allows only existing committers to
> participate,
> > > > > that excludes other potential contributors. This is still an
> > > > > openly-developed project, and we should collaborate in a space
> that is
> > > > > not exclusive to existing committers, but open to
> > > > > non-committer contributors and potential contributors as well.
> > > > > So, while we may
> want
> > > > > to keep a line separating dev activity from user consumption
> > > > > (an important separation that relates to official ASF
> > > > > releases), we
> should
> > > > > not be drawing a line between committer-devs as "internal" and
> > > > > contributor-devs as "external". The website, with its own
> > > > > issue tracker, the ability to render markdown, do reviews, and
> > > > > collaboratively edit, seems like the ideal place to me. We've
> > > > > used
> it
> > > > > before for the same purpose, and I think we should continue to
> > > > > do
> so.
> > > > >
> > > > >
> > > > > >
> > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher
> > > > > > <ctubbsii@apache.org
> >
> > > wrote:
> > > > > >
> > > > > > > So, I agree a space would be helpful. Although it's old
> > > > > > > school
> and
> > > > > > > inconvenient, the mailing list is the canonical place for
> > > discussion.
> > > > > > > We currently use GitHub issues a lot, but that's copied to
> > > > > > > a
> > > mailing
> > > > > > > list (as is our old JIRA space), so if people want to
> participate
> > > > > > > without a GitHub account, they can still do that. There
> > > > > > > are
> certain
> > > > > > > options that are perhaps less convenient, such as just
> > > > > > > using
> the
> > > > > > > mailing list and our dev SVN space, but still more
> > > > > > > appropriate
> than
> > > > > > > options that would be less ubiquitous for potential
> participants.
> > > > > > >
> > > > > > > I think the ASF Confluence is probably fine, for storing,
> editing,
> > > and
> > > > > > > collaborating on shared documents, but decisions about
> > > > > > > those
> would
> > > > > > > still need to be done on the mailing list. If I remember
> > > correctly, we
> > > > > > > used to have a Wiki space, prior to it being transferred
> > > > > > > to Confluence, but it was poorly maintained, so we
> > > > > > > abandoned it in
> > > favor
> > > > > > > of using the website for docs. I could be mis-remembering,
> > > > > > > but
> I
> > > think
> > > > > > > this is the case. It might explain why you can't create a
> > > Confluence
> > > > > > > space.
> > > > > > >
> > > > > > > My preference would be to just use the website. I think
> > > > > > > it's
> fine
> > > to
> > > > > > > have a dev / design area of the website, and we can
> > > > > > > discuss on
> > > GitHub
> > > > > > > issues for the accumulo-website repo. That is a bit less
> convenient
> > > > > > > than Confluence if it's used heavily, but it's more
> > > > > > > convenient
> in
> > > the
> > > > > > > sense that it's more accessible and fits more in line with
> > > > > > > our
> > > current
> > > > > > > mode of operation. Plus, when a document is final, it's
> > > > > > > easy to
> > > link
> > > > > > > to from our documentation, without making users jump to
> > > > > > > another service to view docs.
> > > > > > >
> > > > > > > I would be opposed to using GitHub wiki or a new git repo.
> > > > > > > We
> have
> > > > > > > enough repos. Although it seems like they are free, there
> > > > > > > is
> still
> > > a
> > > > > > > lot of boilerplate work to maintain them, from managing
> > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> .asf.yaml, to
> > > > > > > README, to keeping copyright dates updated in the NOTICE
> > > > > > > file,
> and
> > > > > > > more.
> > > > > > >
> > > > > > > In summary, my preference:
> > > > > > >
> > > > > > > 1. Keep a space in accumulo-website, discuss on GH issues
> > > > > > > and
> > > mailing
> > > > > > > list (strongly preferred)
> > > > > > > 2. Confluence, discuss on mailing list (prefer over other
> options,
> > > but
> > > > > > > not a fan)
> > > > > > > 3. GitHub wiki, discuss on mailing list (strongly prefer
> > > > > > > not
> to use
> > > > > this
> > > > > > > option)
> > > > > > > 4. New GitHub repo, discuss on GH issues and mailing list
> (strongly
> > > > > > > prefer not to use this option)
> > > > > > >
> > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> edcoleman@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Currently, asf cannot create new wiki's because of a
> Confluence
> > > > > issue (
> > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I
> > > > > > > chatted
> with
> > > > > infra
> > > > > > > and in response they created that issue.
> > > > > > > >
> > > > > > > > To expand on this discussion, I would like to toss out
> another
> > > > > > > alternative to discuss / explore. What if we used a
> > > > > > > separate
> > > GitHub
> > > > > > > project, something like Accumulo-Design, just like
> accumulo-proxy
> > > and
> > > > > > > accumulo-examples. As a separate project, it would be
> available
> > > for
> > > > > > > collaboration for the community, but remain separate from
> > > > > > > main
> > > project
> > > > > and
> > > > > > > the website to keep current code / documentation / design
> clearly
> > > > > separate
> > > > > > > from speculative design discussions. As a project:
> > > > > > > >
> > > > > > > > - document history would be preserved with git commit
> history.
> > > > > > > > - document collaboration could be done with normal PR
> > > submissions /
> > > > > > > reviews.
> > > > > > > > - issues could be used to discuss design aspects,
> > > > > > > > capturing
> the
> > > > > comment
> > > > > > > history.
> > > > > > > >
> > > > > > > > The biggest downside is that it would be yet another
> > > > > > > > project
> to
> > > > > follow /
> > > > > > > track.
> > > > > > > >
> > > > > > > > For me, I think the issue is that we need a public,
> collaborative
> > > > > space
> > > > > > > to hold design discussions. Neither the main project or
> > > > > > > the
> > > web-site
> > > > > seem
> > > > > > > quite appropriate and Confluence seems to lack the
> collaboration
> > > that
> > > > > can
> > > > > > > be achieved with github.
> > > > > > > >
> > > > > > > > We need a space to capture the redesign and whatever we
> select
> > > can be
> > > > > > > made to work - I'm just wondering what provides the
> > > > > > > easiest
> forum
> > > to
> > > > > build
> > > > > > > a collaborative space for the Accumulo community.
> > > > > > > >
> > > > > > > > Ed Coleman
> > > > > > > >
> > > > > > > >
> > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > > > > Circling back on this issue - I agree that comments
> > > > > > > > > and
> such
> > > make
> > > > > > > sense for internal design documents. I'm going to create
> > > > > > > an
> INFRA
> > > > > ticket
> > > > > > > for a cwiki space for Accumulo unless there are any objections.
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > >
> > > > > > > > > As mentioned, wikis can provide a streamlined
> > > > > > > > > collaborative
> > > editing
> > > > > > > workflow that's less labor intensive than updating a website.
> They
> > > can
> > > > > > > promote collaboration by providing specific tooling to
> > > > > > > support
> > > > > comments,
> > > > > > > revisions and iteration.
> > > > > > > > >
> > > > > > > > > In terms of preservation, GH wikis act just like any
> > > > > > > > > other
> Git
> > > > > > > repository, with a remote at (for example) git@github.com:
> > > > > > > apache/accumulo.wiki.git
> > > > > > > > > IIRC the pages are just GH flavored markdown. There
> > > > > > > > > are at
> > > least a
> > > > > few
> > > > > > > Apache projects using them.
> > > > > > > > >
> > > > > > > > > However, GH wikis lack some features that I feel are
> important
> > > to
> > > > > > > support collaborative authoring. For example, the ability
> > > > > > > to
> > > comment
> > > > > and
> > > > > > > discuss specific passages in a document is a feature
> > > > > > > that's
> > > present in
> > > > > > > Cwiki, but not in GH wikis. I've come appreciate this this
> > > > > > > in
> my
> > > google
> > > > > > > docs and office workflows, so expect that it would be
> > > > > > > useful
> for
> > > > > Accumulo
> > > > > > > design discussions too.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > kturner@apache.org>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I would like to try a wiki for design documents, I
> > > > > > > > > > think
> it
> > > > > would be
> > > > > > > > > > less cumbersome than the website and we can always
> > > > > > > > > > link
> from
> > > the
> > > > > > > > > > website and issues to the wiki. I think its ok to
> > > > > > > > > > give
> it a
> > > try
> > > > > and
> > > > > > > > > > abandon it in the future, if abandoned would just
> > > > > > > > > > need to
> > > > > properly
> > > > > > > > > > communicate that. The content should be archived in
> Apache
> > > > > > > > > > infrastructure, so if GH wiki does not do that then
> > > > > > > > > > we
> should
> > > > > not use
> > > > > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > > > > >
> > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM
> > > > > > > > > > <dl...@comcast.net>
> > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > I reverted the change. I didn't think it would be
> > > > > > > > > > > a big
> > > deal,
> > > > > but
> > > > > > > if
> > > > > > > > > > > it
> > > > > > > > > > requires discussion, then let's discuss it.
> > > > > > > > > > >
> > > > > > > > > > > I'm looking for a place to host information
> > > > > > > > > > > related to
> > > internal
> > > > > > > > > > > design
> > > > > > > > > > discussions. I envision these to be living documents
> > > > > > > > > > that
> > > will be
> > > > > > > > > > updated over time as the design/implementation
> progresses and
> > > > > that
> > > > > > > > > > other committers will be able to comment on and
> > > > > > > > > > edit. I
> don't
> > > > > feel
> > > > > > > > > > that the website is the correct place for this because:
> > > > > > > > > > >
> > > > > > > > > > > 1. I don't think internal design discussions
> > > > > > > > > > > should
> go
> > > on the
> > > > > > > > > > > project
> > > > > > > > > > website.
> > > > > > > > > > > 2. Changes to the design documents could not be
> > > > > > > > > > > seen
> by
> > > > > others
> > > > > > > > > > > right
> > > > > > > > > > away (IIRC changes to the website are built and
> available at
> > > > > > > > > > https://accumulo.staged.apache.org/, but human
> intervention
> > > is
> > > > > > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > > > > > >
> > > > > > > > > > > I looked in the INFRA issues and other projects
> > > > > > > > > > > are
> using
> > > the
> > > > > GH
> > > > > > > > > > > Wiki
> > > > > > > > > > feature and I saw no mention of backing it up or the
> > > requirement
> > > > > to
> > > > > > > do
> > > > > > > > > > so (maybe they rely on GitHub backing it up?). It
> > > > > > > > > > does
> appear
> > > > > that we
> > > > > > > > > > would need an INFRA ticket so that they can modify
> > > > > > > > > > the
> GitHub
> > > > > project
> > > > > > > > > > settings to lock the GitHub wiki down so that only
> > > committers can
> > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then I
> > > > > > > > > > think
> > > Apache
> > > > > > > > > > Confluence (
> > > > > > > > > > https://cwiki.apache.org) might be an acceptable
> > > alternative.
> > > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > > > Subject: Re: [accumulo] branch main updated:
> > > > > > > > > > > Enable
> Github
> > > > > wiki in
> > > > > > > > > > asf.yaml
> > > > > > > > > > >
> > > > > > > > > > > I don't recall a discussion about this change, but
> > > > > > > > > > > I
> think
> > > it
> > > > > goes
> > > > > > > > > > against previous efforts to make the website the one
> > > canonical
> > > > > > > > > > location for our documentation. I don't even think
> > > > > > > > > > infra
> is
> > > > > backing
> > > > > > > up
> > > > > > > > > > wiki repos, so there wouldn't even be a record of
> > > > > > > > > > the
> wiki
> > > > > contents
> > > > > > > in
> > > > > > > > > > ASF spaces (vs. the main repo, which is backed up to
> GitBox
> > > and
> > > > > the
> > > > > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > > > > >
> > > > > > > > > > > In short, I think this should be reverted and we
> should not
> > > > > use the
> > > > > > > > > > GitHub wiki. If we need to store documents in a
> > > > > > > > > > version
> > > > > controlled
> > > > > > > > > > way, we can store them on the website, or in our
> project's
> > > SVN
> > > > > dev
> > > > > > > > > > space. The wiki is just another place people would
> > > > > > > > > > have
> to
> > > > > follow if
> > > > > > > > > > they want to participate, and I don't think that
> > > > > > > > > > serves
> us.
> > > > > > > Therefore,
> > > > > > > > > > I think we shouldn't use it.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org>
> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > This is an automated email from the ASF
> > > > > > > > > > > > dual-hosted
> git
> > > > > > > repository.
> > > > > > > > > > > >
> > > > > > > > > > > > dlmarion pushed a commit to branch main in
> > > > > > > > > > > > repository
> > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > The following commit(s) were added to
> refs/heads/main by
> > > this
> > > > > > > push:
> > > > > > > > > > > > new ae8a817e7b Enable Github wiki in
> > > > > > > > > > > > asf.yaml
> > > > > ae8a817e7b is
> > > > > > > > > > > > described below
> > > > > > > > > > > >
> > > > > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > > > > >
> > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > > > > ---
> > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > > bc2c943e82..08aa357082
> > > > > > > > > > > > 100644
> > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > > > > - big-data
> > > > > > > > > > > > - hacktoberfest
> > > > > > > > > > > > features:
> > > > > > > > > > > > - wiki: false
> > > > > > > > > > > > + wiki: true
> > > > > > > > > > > > issues: true
> > > > > > > > > > > > projects: true
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
Right, I was just curious if there was any follow-up as I think Ed said
that it was going to be discussed by the INFRA team yesterday. There is at
least one other recent ticket (
https://issues.apache.org/jira/browse/INFRA-24216) where selfserve had an
issue and the INFRA team created the space manually.
On Fri, Mar 3, 2023 at 11:57 AM Christopher <ct...@apache.org> wrote:
> You can track that issue at
> https://issues.apache.org/jira/browse/INFRA-24291
>
> On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com> wrote:
> >
> > Ed,
> >
> > Any update from INFRA on being able to create confluence pages?
> >
> > On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org> wrote:
> >
> > > We've definitely used the website for more than that. We use it to
> > > document things for users, help developers know how to contribute,
> > > store drafts of designs, share user stories via blogs, do release
> > > announcements, and more. There's definitely space on the website to do
> > > this kind of thing, if we want to. We've used it that way before. If
> > > you only see it as a place "for user consumption after everything has
> > > been finalized", then you're missing out on the other ways we
> > > currently use the site, and the ways we've used it in the past.
> > >
> > > With the website, most of the collaboration would happen in the GH
> > > issues about proposed designs or changes to designs, just like we do
> > > today with code or other documentation, which everybody is used to. I
> > > agree it's not as good as Google Docs for on-the-fly
> > > comments/annotations, but I don't think Confluence or Wiki are as good
> > > as that either, and Google Docs isn't really an option... unless you
> > > just want to link to it in the mailing list and stick to Google Docs
> > > from your personal Google account, until it's ready for publication,
> > > which would also be fine (any interested persons can simply request
> > > write access by replying to the message where you shared the link)..
> > >
> > > We are a much smaller project than many others, and we have previously
> > > suffered from having stuff too spread out. Even if other projects find
> > > a separate space valuable for them, I'm not sure it's best for the
> > > Accumulo project. While I think it's useful to examine what other
> > > projects do, I do think we should be careful to adopt anything just
> > > because others find it convenient for them.
> > >
> > > Confluence is my second choice, but with a big gap between it and my
> > > first choice.
> > >
> > > On a personal note: I hate using Confluence, because I think the
> > > navigation is highly unintuitive, as is the permissions model, and I
> > > don't like the idea of learning yet another wiki-syntax (though I've
> > > read Confluence supports some limited Markdown, but probably not the
> > > same as GitHub/Jekyll). I also do not want to set up custom
> > > notifications for watching yet another space. If we use Confluence, I
> > > will probably contribute very infrequently there because of my
> > > frustrations with having used it before. However, that would be my
> > > choice, and should not be a reason the project chooses one over
> > > another. I'm sharing my personal opinion only because it is
> > > influencing my opinion about the website being more accessible, via
> > > our current GitHub PR/issue/Markdown workflows, and I wonder how many
> > > other potential contributors would feel similarly. It's hard to know,
> > > since it seems like a lot of this is subjective, and is going to come
> > > down to a consensus of personal preferences.
> > >
> > > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com>
> wrote:
> > > >
> > > > I don't see the website as an area where we would have collaborative
> > > > discussions about an idea. For example, making comments and
> suggestions
> > > on
> > > > a document like you can do in Google Docs. I see the website as a
> place
> > > > where items are documented for user consumption after everything has
> been
> > > > finalized. I'm not trying to create a private discussion area, I
> think
> > > > anyone can see the wiki (but I think anonymous comments are disabled
> due
> > > to
> > > > spam issues). I see no issue with putting work-in-progress documents
> on a
> > > > wiki and referencing them via emails to the dev list. I think this is
> > > done
> > > > in a lot of other projects. Non-committers that don't have access to
> the
> > > > wiki and want to make comments, suggestions, and ask questions can
> do so
> > > > via the mailing list. I think it's also possible that people can get
> > > > confluence accounts (see
> > > https://issues.apache.org/jira/browse/INFRA-7058),
> > > > so if a non-committer wanted to participate they could.
> > > >
> > > > On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org>
> wrote:
> > > >
> > > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > I'm opposed to using the website for the reasons I specified
> > > earlier, so
> > > > > it
> > > > >
> > > > > Your reasons that I saw were:
> > > > >
> > > > > > 1. I don't think internal design discussions should go on the
> project
> > > > > website.
> > > > >
> > > > > That doesn't look to me like a reason. That appears to just be
> stating
> > > > > the conclusion. Did I miss your reason here?
> > > > >
> > > > > > 2. Changes to the design documents could not be seen by others
> right
> > > > > away (IIRC changes to the website are built and available at
> > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > required
> > > > > to publish it at https://accumulo.apache.org/).
> > > > >
> > > > > What do you mean by "others" here? Do you mean "users", as opposed
> to
> > > > > "developers/contributors"? The ASF draws a distinction between
> > > > > "developers/contributors" and "users" as it pertains to official
> > > > > releases. Releases are intended to be consumed by users, and
> > > > > pre-release stuff is intended to be collaborative, open to all
> > > > > potential developers/contributors. Very very rarely are things
> > > > > reserved exclusively for committers. We don't even have a private
> > > > > committers space (the private mailing list is PMC-private, not
> > > > > committer-private). Having a distinction between users and
> developers
> > > > > doesn't mean we can't publish things on the website... it just
> means
> > > > > that we should be careful about how we do it, which is the same
> care
> > > > > we should take regardless of where we put it. Specifically, the
> care
> > > > > we need to take is to avoid marketing pre-release content to users.
> > > > > One way we can exercise this care for content on our website is
> that
> > > > > we can avoid sharing these unpolished designs by simply not linking
> > > > > them on the site, or by placing them in an area that is clearly
> marked
> > > > > as intended for devs. But, we have no similar distinction between
> > > > > committers and non-committer devs for which we should avoid sharing
> > > > > pre-release content under development. In fact, it is the
> opposite...
> > > > > we should be developing openly so as to allow room for
> non-committers
> > > > > to become committers through participation in development
> activities.
> > > > >
> > > > > As for the staging/publication of the website, that's just a
> mechanic
> > > > > for verifying the website isn't broken before we serve it. It's
> not a
> > > > > mechanism for keeping things internal vs. shared and doesn't have
> > > > > anything to do with the separation between devs and users. We
> already
> > > > > publish Draft contents to the website, as well as
> developer-specific
> > > > > documentation not intended for users.
> > > > >
> > > > > We've even specifically published work-in-progress design documents
> > > > > there, of the same type that seems to be the basis of this
> > > > > conversation (https://accumulo.apache.org/design/system-snapshot).
> I
> > > > > would strongly prefer us to continue to do it this way, rather than
> > > > > create a new space, and have these kinds of things scattered in
> > > > > multiple places.
> > > > >
> > > > > If, on the other hand, you intend to say that these should be
> private
> > > > > because they aren't ready for other potential contributors, then I
> > > > > would argue that we're an openly developed project... if something
> > > > > isn't ready to be shared with other potential contributors /
> > > > > developers, such that you want to keep it internal to existing
> > > > > committers, then it's not ready to be contributed to the project at
> > > > > all... because we don't restrict collaboration to only existing
> > > > > committers. That would prevent others from participating and
> earning
> > > > > the merit to become committers, and that's not something we should
> be
> > > > > doing. Anything that is okay to share with existing committers
> should
> > > > > be okay to share to other potential contributors who want to
> > > > > participate, and should be done in a space that allows them to do
> > > > > that. The website is a perfect space for that, and has everything
> we
> > > > > need. I'm actually not sure about Confluence... I suspect
> > > > > non-committers wouldn't be able to participate there because they
> > > > > probably can't get accounts for it.
> > > > >
> > > > >
> > > > > > looks like we need to
> > > > > > wait for INFRA to fix Confluence. I'd be curious how much we
> need to
> > > use
> > > > > > the mailing list during
> > > > > > the design phase. We can announce meeting dates/times on the
> mailing
> > > list
> > > > > > and post links to
> > > > > > meeting notes in Confluence. Ultimately, decisions made by the
> people
> > > > > that
> > > > > > want to be involved
> > > > > > will turn into pull requests against the codebase which
> comitters can
> > > > > weigh
> > > > > > in on. When you say,
> > > > > > "... but decisions about those would still need to be done on the
> > > mailing
> > > > > > list." Are you saying that
> > > > > > we need to discuss every single design decision on the mailing
> list?
> > > > >
> > > > > Yes and no. I am saying that decisions need to happen on the
> mailing
> > > > > list, but I agree with you that this can be satisfied through pull
> > > > > requests. I just wanted to emphasize that regardless of where we do
> > > > > that pre-decision collaboration, that collaboration should not be
> > > > > misconstrued as a decision to accept those ideas into the project.
> The
> > > > > decision occurs during the PR or other activity that interfaces
> with
> > > > > the mailing list, subsequent to the collaboration in the
> design/idea
> > > > > phase.
> > > > >
> > > > > As for the pre-decision collaboration space we're discussing, I
> just
> > > > > want to be careful that we're not creating such a space in an
> > > > > exclusionary way that allows only existing committers to
> participate,
> > > > > that excludes other potential contributors. This is still an
> > > > > openly-developed project, and we should collaborate in a space
> that is
> > > > > not exclusive to existing committers, but open to non-committer
> > > > > contributors and potential contributors as well. So, while we may
> want
> > > > > to keep a line separating dev activity from user consumption (an
> > > > > important separation that relates to official ASF releases), we
> should
> > > > > not be drawing a line between committer-devs as "internal" and
> > > > > contributor-devs as "external". The website, with its own issue
> > > > > tracker, the ability to render markdown, do reviews, and
> > > > > collaboratively edit, seems like the ideal place to me. We've used
> it
> > > > > before for the same purpose, and I think we should continue to do
> so.
> > > > >
> > > > >
> > > > > >
> > > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher <ctubbsii@apache.org
> >
> > > wrote:
> > > > > >
> > > > > > > So, I agree a space would be helpful. Although it's old school
> and
> > > > > > > inconvenient, the mailing list is the canonical place for
> > > discussion.
> > > > > > > We currently use GitHub issues a lot, but that's copied to a
> > > mailing
> > > > > > > list (as is our old JIRA space), so if people want to
> participate
> > > > > > > without a GitHub account, they can still do that. There are
> certain
> > > > > > > options that are perhaps less convenient, such as just using
> the
> > > > > > > mailing list and our dev SVN space, but still more appropriate
> than
> > > > > > > options that would be less ubiquitous for potential
> participants.
> > > > > > >
> > > > > > > I think the ASF Confluence is probably fine, for storing,
> editing,
> > > and
> > > > > > > collaborating on shared documents, but decisions about those
> would
> > > > > > > still need to be done on the mailing list. If I remember
> > > correctly, we
> > > > > > > used to have a Wiki space, prior to it being transferred to
> > > > > > > Confluence, but it was poorly maintained, so we abandoned it in
> > > favor
> > > > > > > of using the website for docs. I could be mis-remembering, but
> I
> > > think
> > > > > > > this is the case. It might explain why you can't create a
> > > Confluence
> > > > > > > space.
> > > > > > >
> > > > > > > My preference would be to just use the website. I think it's
> fine
> > > to
> > > > > > > have a dev / design area of the website, and we can discuss on
> > > GitHub
> > > > > > > issues for the accumulo-website repo. That is a bit less
> convenient
> > > > > > > than Confluence if it's used heavily, but it's more convenient
> in
> > > the
> > > > > > > sense that it's more accessible and fits more in line with our
> > > current
> > > > > > > mode of operation. Plus, when a document is final, it's easy to
> > > link
> > > > > > > to from our documentation, without making users jump to another
> > > > > > > service to view docs.
> > > > > > >
> > > > > > > I would be opposed to using GitHub wiki or a new git repo. We
> have
> > > > > > > enough repos. Although it seems like they are free, there is
> still
> > > a
> > > > > > > lot of boilerplate work to maintain them, from managing
> > > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to
> .asf.yaml, to
> > > > > > > README, to keeping copyright dates updated in the NOTICE file,
> and
> > > > > > > more.
> > > > > > >
> > > > > > > In summary, my preference:
> > > > > > >
> > > > > > > 1. Keep a space in accumulo-website, discuss on GH issues and
> > > mailing
> > > > > > > list (strongly preferred)
> > > > > > > 2. Confluence, discuss on mailing list (prefer over other
> options,
> > > but
> > > > > > > not a fan)
> > > > > > > 3. GitHub wiki, discuss on mailing list (strongly prefer not
> to use
> > > > > this
> > > > > > > option)
> > > > > > > 4. New GitHub repo, discuss on GH issues and mailing list
> (strongly
> > > > > > > prefer not to use this option)
> > > > > > >
> > > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <
> edcoleman@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Currently, asf cannot create new wiki's because of a
> Confluence
> > > > > issue (
> > > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I chatted
> with
> > > > > infra
> > > > > > > and in response they created that issue.
> > > > > > > >
> > > > > > > > To expand on this discussion, I would like to toss out
> another
> > > > > > > alternative to discuss / explore. What if we used a separate
> > > GitHub
> > > > > > > project, something like Accumulo-Design, just like
> accumulo-proxy
> > > and
> > > > > > > accumulo-examples. As a separate project, it would be
> available
> > > for
> > > > > > > collaboration for the community, but remain separate from main
> > > project
> > > > > and
> > > > > > > the website to keep current code / documentation / design
> clearly
> > > > > separate
> > > > > > > from speculative design discussions. As a project:
> > > > > > > >
> > > > > > > > - document history would be preserved with git commit
> history.
> > > > > > > > - document collaboration could be done with normal PR
> > > submissions /
> > > > > > > reviews.
> > > > > > > > - issues could be used to discuss design aspects, capturing
> the
> > > > > comment
> > > > > > > history.
> > > > > > > >
> > > > > > > > The biggest downside is that it would be yet another project
> to
> > > > > follow /
> > > > > > > track.
> > > > > > > >
> > > > > > > > For me, I think the issue is that we need a public,
> collaborative
> > > > > space
> > > > > > > to hold design discussions. Neither the main project or the
> > > web-site
> > > > > seem
> > > > > > > quite appropriate and Confluence seems to lack the
> collaboration
> > > that
> > > > > can
> > > > > > > be achieved with github.
> > > > > > > >
> > > > > > > > We need a space to capture the redesign and whatever we
> select
> > > can be
> > > > > > > made to work - I'm just wondering what provides the easiest
> forum
> > > to
> > > > > build
> > > > > > > a collaborative space for the Accumulo community.
> > > > > > > >
> > > > > > > > Ed Coleman
> > > > > > > >
> > > > > > > >
> > > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > > > > Circling back on this issue - I agree that comments and
> such
> > > make
> > > > > > > sense for internal design documents. I'm going to create an
> INFRA
> > > > > ticket
> > > > > > > for a cwiki space for Accumulo unless there are any objections.
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > > >
> > > > > > > > > As mentioned, wikis can provide a streamlined collaborative
> > > editing
> > > > > > > workflow that's less labor intensive than updating a website.
> They
> > > can
> > > > > > > promote collaboration by providing specific tooling to support
> > > > > comments,
> > > > > > > revisions and iteration.
> > > > > > > > >
> > > > > > > > > In terms of preservation, GH wikis act just like any other
> Git
> > > > > > > repository, with a remote at (for example) git@github.com:
> > > > > > > apache/accumulo.wiki.git
> > > > > > > > > IIRC the pages are just GH flavored markdown. There are at
> > > least a
> > > > > few
> > > > > > > Apache projects using them.
> > > > > > > > >
> > > > > > > > > However, GH wikis lack some features that I feel are
> important
> > > to
> > > > > > > support collaborative authoring. For example, the ability to
> > > comment
> > > > > and
> > > > > > > discuss specific passages in a document is a feature that's
> > > present in
> > > > > > > Cwiki, but not in GH wikis. I've come appreciate this this in
> my
> > > google
> > > > > > > docs and office workflows, so expect that it would be useful
> for
> > > > > Accumulo
> > > > > > > design discussions too.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > > kturner@apache.org>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I would like to try a wiki for design documents, I think
> it
> > > > > would be
> > > > > > > > > > less cumbersome than the website and we can always link
> from
> > > the
> > > > > > > > > > website and issues to the wiki. I think its ok to give
> it a
> > > try
> > > > > and
> > > > > > > > > > abandon it in the future, if abandoned would just need to
> > > > > properly
> > > > > > > > > > communicate that. The content should be archived in
> Apache
> > > > > > > > > > infrastructure, so if GH wiki does not do that then we
> should
> > > > > not use
> > > > > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > > > > >
> > > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net>
> > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > I reverted the change. I didn't think it would be a big
> > > deal,
> > > > > but
> > > > > > > if
> > > > > > > > > > > it
> > > > > > > > > > requires discussion, then let's discuss it.
> > > > > > > > > > >
> > > > > > > > > > > I'm looking for a place to host information related to
> > > internal
> > > > > > > > > > > design
> > > > > > > > > > discussions. I envision these to be living documents that
> > > will be
> > > > > > > > > > updated over time as the design/implementation
> progresses and
> > > > > that
> > > > > > > > > > other committers will be able to comment on and edit. I
> don't
> > > > > feel
> > > > > > > > > > that the website is the correct place for this because:
> > > > > > > > > > >
> > > > > > > > > > > 1. I don't think internal design discussions should
> go
> > > on the
> > > > > > > > > > > project
> > > > > > > > > > website.
> > > > > > > > > > > 2. Changes to the design documents could not be seen
> by
> > > > > others
> > > > > > > > > > > right
> > > > > > > > > > away (IIRC changes to the website are built and
> available at
> > > > > > > > > > https://accumulo.staged.apache.org/, but human
> intervention
> > > is
> > > > > > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > > > > > >
> > > > > > > > > > > I looked in the INFRA issues and other projects are
> using
> > > the
> > > > > GH
> > > > > > > > > > > Wiki
> > > > > > > > > > feature and I saw no mention of backing it up or the
> > > requirement
> > > > > to
> > > > > > > do
> > > > > > > > > > so (maybe they rely on GitHub backing it up?). It does
> appear
> > > > > that we
> > > > > > > > > > would need an INFRA ticket so that they can modify the
> GitHub
> > > > > project
> > > > > > > > > > settings to lock the GitHub wiki down so that only
> > > committers can
> > > > > > > > > > modify it. If GitHub Wiki is not acceptable, then I think
> > > Apache
> > > > > > > > > > Confluence (
> > > > > > > > > > https://cwiki.apache.org) might be an acceptable
> > > alternative.
> > > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > > > Subject: Re: [accumulo] branch main updated: Enable
> Github
> > > > > wiki in
> > > > > > > > > > asf.yaml
> > > > > > > > > > >
> > > > > > > > > > > I don't recall a discussion about this change, but I
> think
> > > it
> > > > > goes
> > > > > > > > > > against previous efforts to make the website the one
> > > canonical
> > > > > > > > > > location for our documentation. I don't even think infra
> is
> > > > > backing
> > > > > > > up
> > > > > > > > > > wiki repos, so there wouldn't even be a record of the
> wiki
> > > > > contents
> > > > > > > in
> > > > > > > > > > ASF spaces (vs. the main repo, which is backed up to
> GitBox
> > > and
> > > > > the
> > > > > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > > > > >
> > > > > > > > > > > In short, I think this should be reverted and we
> should not
> > > > > use the
> > > > > > > > > > GitHub wiki. If we need to store documents in a version
> > > > > controlled
> > > > > > > > > > way, we can store them on the website, or in our
> project's
> > > SVN
> > > > > dev
> > > > > > > > > > space. The wiki is just another place people would have
> to
> > > > > follow if
> > > > > > > > > > they want to participate, and I don't think that serves
> us.
> > > > > > > Therefore,
> > > > > > > > > > I think we shouldn't use it.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org>
> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > This is an automated email from the ASF dual-hosted
> git
> > > > > > > repository.
> > > > > > > > > > > >
> > > > > > > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > The following commit(s) were added to
> refs/heads/main by
> > > this
> > > > > > > push:
> > > > > > > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml
> > > > > ae8a817e7b is
> > > > > > > > > > > > described below
> > > > > > > > > > > >
> > > > > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > > > > >
> > > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > > > > ---
> > > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > > bc2c943e82..08aa357082
> > > > > > > > > > > > 100644
> > > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > > > > - big-data
> > > > > > > > > > > > - hacktoberfest
> > > > > > > > > > > > features:
> > > > > > > > > > > > - wiki: false
> > > > > > > > > > > > + wiki: true
> > > > > > > > > > > > issues: true
> > > > > > > > > > > > projects: true
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
You can track that issue at https://issues.apache.org/jira/browse/INFRA-24291
On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <dm...@gmail.com> wrote:
>
> Ed,
>
> Any update from INFRA on being able to create confluence pages?
>
> On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org> wrote:
>
> > We've definitely used the website for more than that. We use it to
> > document things for users, help developers know how to contribute,
> > store drafts of designs, share user stories via blogs, do release
> > announcements, and more. There's definitely space on the website to do
> > this kind of thing, if we want to. We've used it that way before. If
> > you only see it as a place "for user consumption after everything has
> > been finalized", then you're missing out on the other ways we
> > currently use the site, and the ways we've used it in the past.
> >
> > With the website, most of the collaboration would happen in the GH
> > issues about proposed designs or changes to designs, just like we do
> > today with code or other documentation, which everybody is used to. I
> > agree it's not as good as Google Docs for on-the-fly
> > comments/annotations, but I don't think Confluence or Wiki are as good
> > as that either, and Google Docs isn't really an option... unless you
> > just want to link to it in the mailing list and stick to Google Docs
> > from your personal Google account, until it's ready for publication,
> > which would also be fine (any interested persons can simply request
> > write access by replying to the message where you shared the link)..
> >
> > We are a much smaller project than many others, and we have previously
> > suffered from having stuff too spread out. Even if other projects find
> > a separate space valuable for them, I'm not sure it's best for the
> > Accumulo project. While I think it's useful to examine what other
> > projects do, I do think we should be careful to adopt anything just
> > because others find it convenient for them.
> >
> > Confluence is my second choice, but with a big gap between it and my
> > first choice.
> >
> > On a personal note: I hate using Confluence, because I think the
> > navigation is highly unintuitive, as is the permissions model, and I
> > don't like the idea of learning yet another wiki-syntax (though I've
> > read Confluence supports some limited Markdown, but probably not the
> > same as GitHub/Jekyll). I also do not want to set up custom
> > notifications for watching yet another space. If we use Confluence, I
> > will probably contribute very infrequently there because of my
> > frustrations with having used it before. However, that would be my
> > choice, and should not be a reason the project chooses one over
> > another. I'm sharing my personal opinion only because it is
> > influencing my opinion about the website being more accessible, via
> > our current GitHub PR/issue/Markdown workflows, and I wonder how many
> > other potential contributors would feel similarly. It's hard to know,
> > since it seems like a lot of this is subjective, and is going to come
> > down to a consensus of personal preferences.
> >
> > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com> wrote:
> > >
> > > I don't see the website as an area where we would have collaborative
> > > discussions about an idea. For example, making comments and suggestions
> > on
> > > a document like you can do in Google Docs. I see the website as a place
> > > where items are documented for user consumption after everything has been
> > > finalized. I'm not trying to create a private discussion area, I think
> > > anyone can see the wiki (but I think anonymous comments are disabled due
> > to
> > > spam issues). I see no issue with putting work-in-progress documents on a
> > > wiki and referencing them via emails to the dev list. I think this is
> > done
> > > in a lot of other projects. Non-committers that don't have access to the
> > > wiki and want to make comments, suggestions, and ask questions can do so
> > > via the mailing list. I think it's also possible that people can get
> > > confluence accounts (see
> > https://issues.apache.org/jira/browse/INFRA-7058),
> > > so if a non-committer wanted to participate they could.
> > >
> > > On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org> wrote:
> > >
> > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com>
> > wrote:
> > > > >
> > > > > I'm opposed to using the website for the reasons I specified
> > earlier, so
> > > > it
> > > >
> > > > Your reasons that I saw were:
> > > >
> > > > > 1. I don't think internal design discussions should go on the project
> > > > website.
> > > >
> > > > That doesn't look to me like a reason. That appears to just be stating
> > > > the conclusion. Did I miss your reason here?
> > > >
> > > > > 2. Changes to the design documents could not be seen by others right
> > > > away (IIRC changes to the website are built and available at
> > > > https://accumulo.staged.apache.org/, but human intervention is
> > required
> > > > to publish it at https://accumulo.apache.org/).
> > > >
> > > > What do you mean by "others" here? Do you mean "users", as opposed to
> > > > "developers/contributors"? The ASF draws a distinction between
> > > > "developers/contributors" and "users" as it pertains to official
> > > > releases. Releases are intended to be consumed by users, and
> > > > pre-release stuff is intended to be collaborative, open to all
> > > > potential developers/contributors. Very very rarely are things
> > > > reserved exclusively for committers. We don't even have a private
> > > > committers space (the private mailing list is PMC-private, not
> > > > committer-private). Having a distinction between users and developers
> > > > doesn't mean we can't publish things on the website... it just means
> > > > that we should be careful about how we do it, which is the same care
> > > > we should take regardless of where we put it. Specifically, the care
> > > > we need to take is to avoid marketing pre-release content to users.
> > > > One way we can exercise this care for content on our website is that
> > > > we can avoid sharing these unpolished designs by simply not linking
> > > > them on the site, or by placing them in an area that is clearly marked
> > > > as intended for devs. But, we have no similar distinction between
> > > > committers and non-committer devs for which we should avoid sharing
> > > > pre-release content under development. In fact, it is the opposite...
> > > > we should be developing openly so as to allow room for non-committers
> > > > to become committers through participation in development activities.
> > > >
> > > > As for the staging/publication of the website, that's just a mechanic
> > > > for verifying the website isn't broken before we serve it. It's not a
> > > > mechanism for keeping things internal vs. shared and doesn't have
> > > > anything to do with the separation between devs and users. We already
> > > > publish Draft contents to the website, as well as developer-specific
> > > > documentation not intended for users.
> > > >
> > > > We've even specifically published work-in-progress design documents
> > > > there, of the same type that seems to be the basis of this
> > > > conversation (https://accumulo.apache.org/design/system-snapshot). I
> > > > would strongly prefer us to continue to do it this way, rather than
> > > > create a new space, and have these kinds of things scattered in
> > > > multiple places.
> > > >
> > > > If, on the other hand, you intend to say that these should be private
> > > > because they aren't ready for other potential contributors, then I
> > > > would argue that we're an openly developed project... if something
> > > > isn't ready to be shared with other potential contributors /
> > > > developers, such that you want to keep it internal to existing
> > > > committers, then it's not ready to be contributed to the project at
> > > > all... because we don't restrict collaboration to only existing
> > > > committers. That would prevent others from participating and earning
> > > > the merit to become committers, and that's not something we should be
> > > > doing. Anything that is okay to share with existing committers should
> > > > be okay to share to other potential contributors who want to
> > > > participate, and should be done in a space that allows them to do
> > > > that. The website is a perfect space for that, and has everything we
> > > > need. I'm actually not sure about Confluence... I suspect
> > > > non-committers wouldn't be able to participate there because they
> > > > probably can't get accounts for it.
> > > >
> > > >
> > > > > looks like we need to
> > > > > wait for INFRA to fix Confluence. I'd be curious how much we need to
> > use
> > > > > the mailing list during
> > > > > the design phase. We can announce meeting dates/times on the mailing
> > list
> > > > > and post links to
> > > > > meeting notes in Confluence. Ultimately, decisions made by the people
> > > > that
> > > > > want to be involved
> > > > > will turn into pull requests against the codebase which comitters can
> > > > weigh
> > > > > in on. When you say,
> > > > > "... but decisions about those would still need to be done on the
> > mailing
> > > > > list." Are you saying that
> > > > > we need to discuss every single design decision on the mailing list?
> > > >
> > > > Yes and no. I am saying that decisions need to happen on the mailing
> > > > list, but I agree with you that this can be satisfied through pull
> > > > requests. I just wanted to emphasize that regardless of where we do
> > > > that pre-decision collaboration, that collaboration should not be
> > > > misconstrued as a decision to accept those ideas into the project. The
> > > > decision occurs during the PR or other activity that interfaces with
> > > > the mailing list, subsequent to the collaboration in the design/idea
> > > > phase.
> > > >
> > > > As for the pre-decision collaboration space we're discussing, I just
> > > > want to be careful that we're not creating such a space in an
> > > > exclusionary way that allows only existing committers to participate,
> > > > that excludes other potential contributors. This is still an
> > > > openly-developed project, and we should collaborate in a space that is
> > > > not exclusive to existing committers, but open to non-committer
> > > > contributors and potential contributors as well. So, while we may want
> > > > to keep a line separating dev activity from user consumption (an
> > > > important separation that relates to official ASF releases), we should
> > > > not be drawing a line between committer-devs as "internal" and
> > > > contributor-devs as "external". The website, with its own issue
> > > > tracker, the ability to render markdown, do reviews, and
> > > > collaboratively edit, seems like the ideal place to me. We've used it
> > > > before for the same purpose, and I think we should continue to do so.
> > > >
> > > >
> > > > >
> > > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org>
> > wrote:
> > > > >
> > > > > > So, I agree a space would be helpful. Although it's old school and
> > > > > > inconvenient, the mailing list is the canonical place for
> > discussion.
> > > > > > We currently use GitHub issues a lot, but that's copied to a
> > mailing
> > > > > > list (as is our old JIRA space), so if people want to participate
> > > > > > without a GitHub account, they can still do that. There are certain
> > > > > > options that are perhaps less convenient, such as just using the
> > > > > > mailing list and our dev SVN space, but still more appropriate than
> > > > > > options that would be less ubiquitous for potential participants.
> > > > > >
> > > > > > I think the ASF Confluence is probably fine, for storing, editing,
> > and
> > > > > > collaborating on shared documents, but decisions about those would
> > > > > > still need to be done on the mailing list. If I remember
> > correctly, we
> > > > > > used to have a Wiki space, prior to it being transferred to
> > > > > > Confluence, but it was poorly maintained, so we abandoned it in
> > favor
> > > > > > of using the website for docs. I could be mis-remembering, but I
> > think
> > > > > > this is the case. It might explain why you can't create a
> > Confluence
> > > > > > space.
> > > > > >
> > > > > > My preference would be to just use the website. I think it's fine
> > to
> > > > > > have a dev / design area of the website, and we can discuss on
> > GitHub
> > > > > > issues for the accumulo-website repo. That is a bit less convenient
> > > > > > than Confluence if it's used heavily, but it's more convenient in
> > the
> > > > > > sense that it's more accessible and fits more in line with our
> > current
> > > > > > mode of operation. Plus, when a document is final, it's easy to
> > link
> > > > > > to from our documentation, without making users jump to another
> > > > > > service to view docs.
> > > > > >
> > > > > > I would be opposed to using GitHub wiki or a new git repo. We have
> > > > > > enough repos. Although it seems like they are free, there is still
> > a
> > > > > > lot of boilerplate work to maintain them, from managing
> > > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > > > > > README, to keeping copyright dates updated in the NOTICE file, and
> > > > > > more.
> > > > > >
> > > > > > In summary, my preference:
> > > > > >
> > > > > > 1. Keep a space in accumulo-website, discuss on GH issues and
> > mailing
> > > > > > list (strongly preferred)
> > > > > > 2. Confluence, discuss on mailing list (prefer over other options,
> > but
> > > > > > not a fan)
> > > > > > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use
> > > > this
> > > > > > option)
> > > > > > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > > > > > prefer not to use this option)
> > > > > >
> > > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > Currently, asf cannot create new wiki's because of a Confluence
> > > > issue (
> > > > > > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with
> > > > infra
> > > > > > and in response they created that issue.
> > > > > > >
> > > > > > > To expand on this discussion, I would like to toss out another
> > > > > > alternative to discuss / explore. What if we used a separate
> > GitHub
> > > > > > project, something like Accumulo-Design, just like accumulo-proxy
> > and
> > > > > > accumulo-examples. As a separate project, it would be available
> > for
> > > > > > collaboration for the community, but remain separate from main
> > project
> > > > and
> > > > > > the website to keep current code / documentation / design clearly
> > > > separate
> > > > > > from speculative design discussions. As a project:
> > > > > > >
> > > > > > > - document history would be preserved with git commit history.
> > > > > > > - document collaboration could be done with normal PR
> > submissions /
> > > > > > reviews.
> > > > > > > - issues could be used to discuss design aspects, capturing the
> > > > comment
> > > > > > history.
> > > > > > >
> > > > > > > The biggest downside is that it would be yet another project to
> > > > follow /
> > > > > > track.
> > > > > > >
> > > > > > > For me, I think the issue is that we need a public, collaborative
> > > > space
> > > > > > to hold design discussions. Neither the main project or the
> > web-site
> > > > seem
> > > > > > quite appropriate and Confluence seems to lack the collaboration
> > that
> > > > can
> > > > > > be achieved with github.
> > > > > > >
> > > > > > > We need a space to capture the redesign and whatever we select
> > can be
> > > > > > made to work - I'm just wondering what provides the easiest forum
> > to
> > > > build
> > > > > > a collaborative space for the Accumulo community.
> > > > > > >
> > > > > > > Ed Coleman
> > > > > > >
> > > > > > >
> > > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > > > Circling back on this issue - I agree that comments and such
> > make
> > > > > > sense for internal design documents. I'm going to create an INFRA
> > > > ticket
> > > > > > for a cwiki space for Accumulo unless there are any objections.
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > > > To: dev@accumulo.apache.org
> > > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > > >
> > > > > > > > As mentioned, wikis can provide a streamlined collaborative
> > editing
> > > > > > workflow that's less labor intensive than updating a website. They
> > can
> > > > > > promote collaboration by providing specific tooling to support
> > > > comments,
> > > > > > revisions and iteration.
> > > > > > > >
> > > > > > > > In terms of preservation, GH wikis act just like any other Git
> > > > > > repository, with a remote at (for example) git@github.com:
> > > > > > apache/accumulo.wiki.git
> > > > > > > > IIRC the pages are just GH flavored markdown. There are at
> > least a
> > > > few
> > > > > > Apache projects using them.
> > > > > > > >
> > > > > > > > However, GH wikis lack some features that I feel are important
> > to
> > > > > > support collaborative authoring. For example, the ability to
> > comment
> > > > and
> > > > > > discuss specific passages in a document is a feature that's
> > present in
> > > > > > Cwiki, but not in GH wikis. I've come appreciate this this in my
> > google
> > > > > > docs and office workflows, so expect that it would be useful for
> > > > Accumulo
> > > > > > design discussions too.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> > kturner@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > I would like to try a wiki for design documents, I think it
> > > > would be
> > > > > > > > > less cumbersome than the website and we can always link from
> > the
> > > > > > > > > website and issues to the wiki. I think its ok to give it a
> > try
> > > > and
> > > > > > > > > abandon it in the future, if abandoned would just need to
> > > > properly
> > > > > > > > > communicate that. The content should be archived in Apache
> > > > > > > > > infrastructure, so if GH wiki does not do that then we should
> > > > not use
> > > > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > > > >
> > > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net>
> > wrote:
> > > > > > > > > >
> > > > > > > > > > I reverted the change. I didn't think it would be a big
> > deal,
> > > > but
> > > > > > if
> > > > > > > > > > it
> > > > > > > > > requires discussion, then let's discuss it.
> > > > > > > > > >
> > > > > > > > > > I'm looking for a place to host information related to
> > internal
> > > > > > > > > > design
> > > > > > > > > discussions. I envision these to be living documents that
> > will be
> > > > > > > > > updated over time as the design/implementation progresses and
> > > > that
> > > > > > > > > other committers will be able to comment on and edit. I don't
> > > > feel
> > > > > > > > > that the website is the correct place for this because:
> > > > > > > > > >
> > > > > > > > > > 1. I don't think internal design discussions should go
> > on the
> > > > > > > > > > project
> > > > > > > > > website.
> > > > > > > > > > 2. Changes to the design documents could not be seen by
> > > > others
> > > > > > > > > > right
> > > > > > > > > away (IIRC changes to the website are built and available at
> > > > > > > > > https://accumulo.staged.apache.org/, but human intervention
> > is
> > > > > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > > > > >
> > > > > > > > > > I looked in the INFRA issues and other projects are using
> > the
> > > > GH
> > > > > > > > > > Wiki
> > > > > > > > > feature and I saw no mention of backing it up or the
> > requirement
> > > > to
> > > > > > do
> > > > > > > > > so (maybe they rely on GitHub backing it up?). It does appear
> > > > that we
> > > > > > > > > would need an INFRA ticket so that they can modify the GitHub
> > > > project
> > > > > > > > > settings to lock the GitHub wiki down so that only
> > committers can
> > > > > > > > > modify it. If GitHub Wiki is not acceptable, then I think
> > Apache
> > > > > > > > > Confluence (
> > > > > > > > > https://cwiki.apache.org) might be an acceptable
> > alternative.
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > > Subject: Re: [accumulo] branch main updated: Enable Github
> > > > wiki in
> > > > > > > > > asf.yaml
> > > > > > > > > >
> > > > > > > > > > I don't recall a discussion about this change, but I think
> > it
> > > > goes
> > > > > > > > > against previous efforts to make the website the one
> > canonical
> > > > > > > > > location for our documentation. I don't even think infra is
> > > > backing
> > > > > > up
> > > > > > > > > wiki repos, so there wouldn't even be a record of the wiki
> > > > contents
> > > > > > in
> > > > > > > > > ASF spaces (vs. the main repo, which is backed up to GitBox
> > and
> > > > the
> > > > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > > > >
> > > > > > > > > > In short, I think this should be reverted and we should not
> > > > use the
> > > > > > > > > GitHub wiki. If we need to store documents in a version
> > > > controlled
> > > > > > > > > way, we can store them on the website, or in our project's
> > SVN
> > > > dev
> > > > > > > > > space. The wiki is just another place people would have to
> > > > follow if
> > > > > > > > > they want to participate, and I don't think that serves us.
> > > > > > Therefore,
> > > > > > > > > I think we shouldn't use it.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > > > > > >
> > > > > > > > > > > This is an automated email from the ASF dual-hosted git
> > > > > > repository.
> > > > > > > > > > >
> > > > > > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The following commit(s) were added to refs/heads/main by
> > this
> > > > > > push:
> > > > > > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml
> > > > ae8a817e7b is
> > > > > > > > > > > described below
> > > > > > > > > > >
> > > > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > > > >
> > > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > > > ---
> > > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > > bc2c943e82..08aa357082
> > > > > > > > > > > 100644
> > > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > > > - big-data
> > > > > > > > > > > - hacktoberfest
> > > > > > > > > > > features:
> > > > > > > > > > > - wiki: false
> > > > > > > > > > > + wiki: true
> > > > > > > > > > > issues: true
> > > > > > > > > > > projects: true
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
Ed,
Any update from INFRA on being able to create confluence pages?
On Thu, Mar 2, 2023 at 4:07 PM Christopher <ct...@apache.org> wrote:
> We've definitely used the website for more than that. We use it to
> document things for users, help developers know how to contribute,
> store drafts of designs, share user stories via blogs, do release
> announcements, and more. There's definitely space on the website to do
> this kind of thing, if we want to. We've used it that way before. If
> you only see it as a place "for user consumption after everything has
> been finalized", then you're missing out on the other ways we
> currently use the site, and the ways we've used it in the past.
>
> With the website, most of the collaboration would happen in the GH
> issues about proposed designs or changes to designs, just like we do
> today with code or other documentation, which everybody is used to. I
> agree it's not as good as Google Docs for on-the-fly
> comments/annotations, but I don't think Confluence or Wiki are as good
> as that either, and Google Docs isn't really an option... unless you
> just want to link to it in the mailing list and stick to Google Docs
> from your personal Google account, until it's ready for publication,
> which would also be fine (any interested persons can simply request
> write access by replying to the message where you shared the link)..
>
> We are a much smaller project than many others, and we have previously
> suffered from having stuff too spread out. Even if other projects find
> a separate space valuable for them, I'm not sure it's best for the
> Accumulo project. While I think it's useful to examine what other
> projects do, I do think we should be careful to adopt anything just
> because others find it convenient for them.
>
> Confluence is my second choice, but with a big gap between it and my
> first choice.
>
> On a personal note: I hate using Confluence, because I think the
> navigation is highly unintuitive, as is the permissions model, and I
> don't like the idea of learning yet another wiki-syntax (though I've
> read Confluence supports some limited Markdown, but probably not the
> same as GitHub/Jekyll). I also do not want to set up custom
> notifications for watching yet another space. If we use Confluence, I
> will probably contribute very infrequently there because of my
> frustrations with having used it before. However, that would be my
> choice, and should not be a reason the project chooses one over
> another. I'm sharing my personal opinion only because it is
> influencing my opinion about the website being more accessible, via
> our current GitHub PR/issue/Markdown workflows, and I wonder how many
> other potential contributors would feel similarly. It's hard to know,
> since it seems like a lot of this is subjective, and is going to come
> down to a consensus of personal preferences.
>
> On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com> wrote:
> >
> > I don't see the website as an area where we would have collaborative
> > discussions about an idea. For example, making comments and suggestions
> on
> > a document like you can do in Google Docs. I see the website as a place
> > where items are documented for user consumption after everything has been
> > finalized. I'm not trying to create a private discussion area, I think
> > anyone can see the wiki (but I think anonymous comments are disabled due
> to
> > spam issues). I see no issue with putting work-in-progress documents on a
> > wiki and referencing them via emails to the dev list. I think this is
> done
> > in a lot of other projects. Non-committers that don't have access to the
> > wiki and want to make comments, suggestions, and ask questions can do so
> > via the mailing list. I think it's also possible that people can get
> > confluence accounts (see
> https://issues.apache.org/jira/browse/INFRA-7058),
> > so if a non-committer wanted to participate they could.
> >
> > On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org> wrote:
> >
> > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com>
> wrote:
> > > >
> > > > I'm opposed to using the website for the reasons I specified
> earlier, so
> > > it
> > >
> > > Your reasons that I saw were:
> > >
> > > > 1. I don't think internal design discussions should go on the project
> > > website.
> > >
> > > That doesn't look to me like a reason. That appears to just be stating
> > > the conclusion. Did I miss your reason here?
> > >
> > > > 2. Changes to the design documents could not be seen by others right
> > > away (IIRC changes to the website are built and available at
> > > https://accumulo.staged.apache.org/, but human intervention is
> required
> > > to publish it at https://accumulo.apache.org/).
> > >
> > > What do you mean by "others" here? Do you mean "users", as opposed to
> > > "developers/contributors"? The ASF draws a distinction between
> > > "developers/contributors" and "users" as it pertains to official
> > > releases. Releases are intended to be consumed by users, and
> > > pre-release stuff is intended to be collaborative, open to all
> > > potential developers/contributors. Very very rarely are things
> > > reserved exclusively for committers. We don't even have a private
> > > committers space (the private mailing list is PMC-private, not
> > > committer-private). Having a distinction between users and developers
> > > doesn't mean we can't publish things on the website... it just means
> > > that we should be careful about how we do it, which is the same care
> > > we should take regardless of where we put it. Specifically, the care
> > > we need to take is to avoid marketing pre-release content to users.
> > > One way we can exercise this care for content on our website is that
> > > we can avoid sharing these unpolished designs by simply not linking
> > > them on the site, or by placing them in an area that is clearly marked
> > > as intended for devs. But, we have no similar distinction between
> > > committers and non-committer devs for which we should avoid sharing
> > > pre-release content under development. In fact, it is the opposite...
> > > we should be developing openly so as to allow room for non-committers
> > > to become committers through participation in development activities.
> > >
> > > As for the staging/publication of the website, that's just a mechanic
> > > for verifying the website isn't broken before we serve it. It's not a
> > > mechanism for keeping things internal vs. shared and doesn't have
> > > anything to do with the separation between devs and users. We already
> > > publish Draft contents to the website, as well as developer-specific
> > > documentation not intended for users.
> > >
> > > We've even specifically published work-in-progress design documents
> > > there, of the same type that seems to be the basis of this
> > > conversation (https://accumulo.apache.org/design/system-snapshot). I
> > > would strongly prefer us to continue to do it this way, rather than
> > > create a new space, and have these kinds of things scattered in
> > > multiple places.
> > >
> > > If, on the other hand, you intend to say that these should be private
> > > because they aren't ready for other potential contributors, then I
> > > would argue that we're an openly developed project... if something
> > > isn't ready to be shared with other potential contributors /
> > > developers, such that you want to keep it internal to existing
> > > committers, then it's not ready to be contributed to the project at
> > > all... because we don't restrict collaboration to only existing
> > > committers. That would prevent others from participating and earning
> > > the merit to become committers, and that's not something we should be
> > > doing. Anything that is okay to share with existing committers should
> > > be okay to share to other potential contributors who want to
> > > participate, and should be done in a space that allows them to do
> > > that. The website is a perfect space for that, and has everything we
> > > need. I'm actually not sure about Confluence... I suspect
> > > non-committers wouldn't be able to participate there because they
> > > probably can't get accounts for it.
> > >
> > >
> > > > looks like we need to
> > > > wait for INFRA to fix Confluence. I'd be curious how much we need to
> use
> > > > the mailing list during
> > > > the design phase. We can announce meeting dates/times on the mailing
> list
> > > > and post links to
> > > > meeting notes in Confluence. Ultimately, decisions made by the people
> > > that
> > > > want to be involved
> > > > will turn into pull requests against the codebase which comitters can
> > > weigh
> > > > in on. When you say,
> > > > "... but decisions about those would still need to be done on the
> mailing
> > > > list." Are you saying that
> > > > we need to discuss every single design decision on the mailing list?
> > >
> > > Yes and no. I am saying that decisions need to happen on the mailing
> > > list, but I agree with you that this can be satisfied through pull
> > > requests. I just wanted to emphasize that regardless of where we do
> > > that pre-decision collaboration, that collaboration should not be
> > > misconstrued as a decision to accept those ideas into the project. The
> > > decision occurs during the PR or other activity that interfaces with
> > > the mailing list, subsequent to the collaboration in the design/idea
> > > phase.
> > >
> > > As for the pre-decision collaboration space we're discussing, I just
> > > want to be careful that we're not creating such a space in an
> > > exclusionary way that allows only existing committers to participate,
> > > that excludes other potential contributors. This is still an
> > > openly-developed project, and we should collaborate in a space that is
> > > not exclusive to existing committers, but open to non-committer
> > > contributors and potential contributors as well. So, while we may want
> > > to keep a line separating dev activity from user consumption (an
> > > important separation that relates to official ASF releases), we should
> > > not be drawing a line between committer-devs as "internal" and
> > > contributor-devs as "external". The website, with its own issue
> > > tracker, the ability to render markdown, do reviews, and
> > > collaboratively edit, seems like the ideal place to me. We've used it
> > > before for the same purpose, and I think we should continue to do so.
> > >
> > >
> > > >
> > > > On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org>
> wrote:
> > > >
> > > > > So, I agree a space would be helpful. Although it's old school and
> > > > > inconvenient, the mailing list is the canonical place for
> discussion.
> > > > > We currently use GitHub issues a lot, but that's copied to a
> mailing
> > > > > list (as is our old JIRA space), so if people want to participate
> > > > > without a GitHub account, they can still do that. There are certain
> > > > > options that are perhaps less convenient, such as just using the
> > > > > mailing list and our dev SVN space, but still more appropriate than
> > > > > options that would be less ubiquitous for potential participants.
> > > > >
> > > > > I think the ASF Confluence is probably fine, for storing, editing,
> and
> > > > > collaborating on shared documents, but decisions about those would
> > > > > still need to be done on the mailing list. If I remember
> correctly, we
> > > > > used to have a Wiki space, prior to it being transferred to
> > > > > Confluence, but it was poorly maintained, so we abandoned it in
> favor
> > > > > of using the website for docs. I could be mis-remembering, but I
> think
> > > > > this is the case. It might explain why you can't create a
> Confluence
> > > > > space.
> > > > >
> > > > > My preference would be to just use the website. I think it's fine
> to
> > > > > have a dev / design area of the website, and we can discuss on
> GitHub
> > > > > issues for the accumulo-website repo. That is a bit less convenient
> > > > > than Confluence if it's used heavily, but it's more convenient in
> the
> > > > > sense that it's more accessible and fits more in line with our
> current
> > > > > mode of operation. Plus, when a document is final, it's easy to
> link
> > > > > to from our documentation, without making users jump to another
> > > > > service to view docs.
> > > > >
> > > > > I would be opposed to using GitHub wiki or a new git repo. We have
> > > > > enough repos. Although it seems like they are free, there is still
> a
> > > > > lot of boilerplate work to maintain them, from managing
> > > > > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > > > > README, to keeping copyright dates updated in the NOTICE file, and
> > > > > more.
> > > > >
> > > > > In summary, my preference:
> > > > >
> > > > > 1. Keep a space in accumulo-website, discuss on GH issues and
> mailing
> > > > > list (strongly preferred)
> > > > > 2. Confluence, discuss on mailing list (prefer over other options,
> but
> > > > > not a fan)
> > > > > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use
> > > this
> > > > > option)
> > > > > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > > > > prefer not to use this option)
> > > > >
> > > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org>
> > > wrote:
> > > > > >
> > > > > > Currently, asf cannot create new wiki's because of a Confluence
> > > issue (
> > > > > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with
> > > infra
> > > > > and in response they created that issue.
> > > > > >
> > > > > > To expand on this discussion, I would like to toss out another
> > > > > alternative to discuss / explore. What if we used a separate
> GitHub
> > > > > project, something like Accumulo-Design, just like accumulo-proxy
> and
> > > > > accumulo-examples. As a separate project, it would be available
> for
> > > > > collaboration for the community, but remain separate from main
> project
> > > and
> > > > > the website to keep current code / documentation / design clearly
> > > separate
> > > > > from speculative design discussions. As a project:
> > > > > >
> > > > > > - document history would be preserved with git commit history.
> > > > > > - document collaboration could be done with normal PR
> submissions /
> > > > > reviews.
> > > > > > - issues could be used to discuss design aspects, capturing the
> > > comment
> > > > > history.
> > > > > >
> > > > > > The biggest downside is that it would be yet another project to
> > > follow /
> > > > > track.
> > > > > >
> > > > > > For me, I think the issue is that we need a public, collaborative
> > > space
> > > > > to hold design discussions. Neither the main project or the
> web-site
> > > seem
> > > > > quite appropriate and Confluence seems to lack the collaboration
> that
> > > can
> > > > > be achieved with github.
> > > > > >
> > > > > > We need a space to capture the redesign and whatever we select
> can be
> > > > > made to work - I'm just wondering what provides the easiest forum
> to
> > > build
> > > > > a collaborative space for the Accumulo community.
> > > > > >
> > > > > > Ed Coleman
> > > > > >
> > > > > >
> > > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > > Circling back on this issue - I agree that comments and such
> make
> > > > > sense for internal design documents. I'm going to create an INFRA
> > > ticket
> > > > > for a cwiki space for Accumulo unless there are any objections.
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > > To: dev@accumulo.apache.org
> > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > >
> > > > > > > As mentioned, wikis can provide a streamlined collaborative
> editing
> > > > > workflow that's less labor intensive than updating a website. They
> can
> > > > > promote collaboration by providing specific tooling to support
> > > comments,
> > > > > revisions and iteration.
> > > > > > >
> > > > > > > In terms of preservation, GH wikis act just like any other Git
> > > > > repository, with a remote at (for example) git@github.com:
> > > > > apache/accumulo.wiki.git
> > > > > > > IIRC the pages are just GH flavored markdown. There are at
> least a
> > > few
> > > > > Apache projects using them.
> > > > > > >
> > > > > > > However, GH wikis lack some features that I feel are important
> to
> > > > > support collaborative authoring. For example, the ability to
> comment
> > > and
> > > > > discuss specific passages in a document is a feature that's
> present in
> > > > > Cwiki, but not in GH wikis. I've come appreciate this this in my
> google
> > > > > docs and office workflows, so expect that it would be useful for
> > > Accumulo
> > > > > design discussions too.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <
> kturner@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > I would like to try a wiki for design documents, I think it
> > > would be
> > > > > > > > less cumbersome than the website and we can always link from
> the
> > > > > > > > website and issues to the wiki. I think its ok to give it a
> try
> > > and
> > > > > > > > abandon it in the future, if abandoned would just need to
> > > properly
> > > > > > > > communicate that. The content should be archived in Apache
> > > > > > > > infrastructure, so if GH wiki does not do that then we should
> > > not use
> > > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > > >
> > > > > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net>
> wrote:
> > > > > > > > >
> > > > > > > > > I reverted the change. I didn't think it would be a big
> deal,
> > > but
> > > > > if
> > > > > > > > > it
> > > > > > > > requires discussion, then let's discuss it.
> > > > > > > > >
> > > > > > > > > I'm looking for a place to host information related to
> internal
> > > > > > > > > design
> > > > > > > > discussions. I envision these to be living documents that
> will be
> > > > > > > > updated over time as the design/implementation progresses and
> > > that
> > > > > > > > other committers will be able to comment on and edit. I don't
> > > feel
> > > > > > > > that the website is the correct place for this because:
> > > > > > > > >
> > > > > > > > > 1. I don't think internal design discussions should go
> on the
> > > > > > > > > project
> > > > > > > > website.
> > > > > > > > > 2. Changes to the design documents could not be seen by
> > > others
> > > > > > > > > right
> > > > > > > > away (IIRC changes to the website are built and available at
> > > > > > > > https://accumulo.staged.apache.org/, but human intervention
> is
> > > > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > > > >
> > > > > > > > > I looked in the INFRA issues and other projects are using
> the
> > > GH
> > > > > > > > > Wiki
> > > > > > > > feature and I saw no mention of backing it up or the
> requirement
> > > to
> > > > > do
> > > > > > > > so (maybe they rely on GitHub backing it up?). It does appear
> > > that we
> > > > > > > > would need an INFRA ticket so that they can modify the GitHub
> > > project
> > > > > > > > settings to lock the GitHub wiki down so that only
> committers can
> > > > > > > > modify it. If GitHub Wiki is not acceptable, then I think
> Apache
> > > > > > > > Confluence (
> > > > > > > > https://cwiki.apache.org) might be an acceptable
> alternative.
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > > Subject: Re: [accumulo] branch main updated: Enable Github
> > > wiki in
> > > > > > > > asf.yaml
> > > > > > > > >
> > > > > > > > > I don't recall a discussion about this change, but I think
> it
> > > goes
> > > > > > > > against previous efforts to make the website the one
> canonical
> > > > > > > > location for our documentation. I don't even think infra is
> > > backing
> > > > > up
> > > > > > > > wiki repos, so there wouldn't even be a record of the wiki
> > > contents
> > > > > in
> > > > > > > > ASF spaces (vs. the main repo, which is backed up to GitBox
> and
> > > the
> > > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > > >
> > > > > > > > > In short, I think this should be reverted and we should not
> > > use the
> > > > > > > > GitHub wiki. If we need to store documents in a version
> > > controlled
> > > > > > > > way, we can store them on the website, or in our project's
> SVN
> > > dev
> > > > > > > > space. The wiki is just another place people would have to
> > > follow if
> > > > > > > > they want to participate, and I don't think that serves us.
> > > > > Therefore,
> > > > > > > > I think we shouldn't use it.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > > > > >
> > > > > > > > > > This is an automated email from the ASF dual-hosted git
> > > > > repository.
> > > > > > > > > >
> > > > > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The following commit(s) were added to refs/heads/main by
> this
> > > > > push:
> > > > > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml
> > > ae8a817e7b is
> > > > > > > > > > described below
> > > > > > > > > >
> > > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > > >
> > > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > > ---
> > > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > > bc2c943e82..08aa357082
> > > > > > > > > > 100644
> > > > > > > > > > --- a/.asf.yaml
> > > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > > - big-data
> > > > > > > > > > - hacktoberfest
> > > > > > > > > > features:
> > > > > > > > > > - wiki: false
> > > > > > > > > > + wiki: true
> > > > > > > > > > issues: true
> > > > > > > > > > projects: true
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
We've definitely used the website for more than that. We use it to
document things for users, help developers know how to contribute,
store drafts of designs, share user stories via blogs, do release
announcements, and more. There's definitely space on the website to do
this kind of thing, if we want to. We've used it that way before. If
you only see it as a place "for user consumption after everything has
been finalized", then you're missing out on the other ways we
currently use the site, and the ways we've used it in the past.
With the website, most of the collaboration would happen in the GH
issues about proposed designs or changes to designs, just like we do
today with code or other documentation, which everybody is used to. I
agree it's not as good as Google Docs for on-the-fly
comments/annotations, but I don't think Confluence or Wiki are as good
as that either, and Google Docs isn't really an option... unless you
just want to link to it in the mailing list and stick to Google Docs
from your personal Google account, until it's ready for publication,
which would also be fine (any interested persons can simply request
write access by replying to the message where you shared the link)..
We are a much smaller project than many others, and we have previously
suffered from having stuff too spread out. Even if other projects find
a separate space valuable for them, I'm not sure it's best for the
Accumulo project. While I think it's useful to examine what other
projects do, I do think we should be careful to adopt anything just
because others find it convenient for them.
Confluence is my second choice, but with a big gap between it and my
first choice.
On a personal note: I hate using Confluence, because I think the
navigation is highly unintuitive, as is the permissions model, and I
don't like the idea of learning yet another wiki-syntax (though I've
read Confluence supports some limited Markdown, but probably not the
same as GitHub/Jekyll). I also do not want to set up custom
notifications for watching yet another space. If we use Confluence, I
will probably contribute very infrequently there because of my
frustrations with having used it before. However, that would be my
choice, and should not be a reason the project chooses one over
another. I'm sharing my personal opinion only because it is
influencing my opinion about the website being more accessible, via
our current GitHub PR/issue/Markdown workflows, and I wonder how many
other potential contributors would feel similarly. It's hard to know,
since it seems like a lot of this is subjective, and is going to come
down to a consensus of personal preferences.
On Thu, Mar 2, 2023 at 3:46 PM Dave Marion <dm...@gmail.com> wrote:
>
> I don't see the website as an area where we would have collaborative
> discussions about an idea. For example, making comments and suggestions on
> a document like you can do in Google Docs. I see the website as a place
> where items are documented for user consumption after everything has been
> finalized. I'm not trying to create a private discussion area, I think
> anyone can see the wiki (but I think anonymous comments are disabled due to
> spam issues). I see no issue with putting work-in-progress documents on a
> wiki and referencing them via emails to the dev list. I think this is done
> in a lot of other projects. Non-committers that don't have access to the
> wiki and want to make comments, suggestions, and ask questions can do so
> via the mailing list. I think it's also possible that people can get
> confluence accounts (see https://issues.apache.org/jira/browse/INFRA-7058),
> so if a non-committer wanted to participate they could.
>
> On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org> wrote:
>
> > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com> wrote:
> > >
> > > I'm opposed to using the website for the reasons I specified earlier, so
> > it
> >
> > Your reasons that I saw were:
> >
> > > 1. I don't think internal design discussions should go on the project
> > website.
> >
> > That doesn't look to me like a reason. That appears to just be stating
> > the conclusion. Did I miss your reason here?
> >
> > > 2. Changes to the design documents could not be seen by others right
> > away (IIRC changes to the website are built and available at
> > https://accumulo.staged.apache.org/, but human intervention is required
> > to publish it at https://accumulo.apache.org/).
> >
> > What do you mean by "others" here? Do you mean "users", as opposed to
> > "developers/contributors"? The ASF draws a distinction between
> > "developers/contributors" and "users" as it pertains to official
> > releases. Releases are intended to be consumed by users, and
> > pre-release stuff is intended to be collaborative, open to all
> > potential developers/contributors. Very very rarely are things
> > reserved exclusively for committers. We don't even have a private
> > committers space (the private mailing list is PMC-private, not
> > committer-private). Having a distinction between users and developers
> > doesn't mean we can't publish things on the website... it just means
> > that we should be careful about how we do it, which is the same care
> > we should take regardless of where we put it. Specifically, the care
> > we need to take is to avoid marketing pre-release content to users.
> > One way we can exercise this care for content on our website is that
> > we can avoid sharing these unpolished designs by simply not linking
> > them on the site, or by placing them in an area that is clearly marked
> > as intended for devs. But, we have no similar distinction between
> > committers and non-committer devs for which we should avoid sharing
> > pre-release content under development. In fact, it is the opposite...
> > we should be developing openly so as to allow room for non-committers
> > to become committers through participation in development activities.
> >
> > As for the staging/publication of the website, that's just a mechanic
> > for verifying the website isn't broken before we serve it. It's not a
> > mechanism for keeping things internal vs. shared and doesn't have
> > anything to do with the separation between devs and users. We already
> > publish Draft contents to the website, as well as developer-specific
> > documentation not intended for users.
> >
> > We've even specifically published work-in-progress design documents
> > there, of the same type that seems to be the basis of this
> > conversation (https://accumulo.apache.org/design/system-snapshot). I
> > would strongly prefer us to continue to do it this way, rather than
> > create a new space, and have these kinds of things scattered in
> > multiple places.
> >
> > If, on the other hand, you intend to say that these should be private
> > because they aren't ready for other potential contributors, then I
> > would argue that we're an openly developed project... if something
> > isn't ready to be shared with other potential contributors /
> > developers, such that you want to keep it internal to existing
> > committers, then it's not ready to be contributed to the project at
> > all... because we don't restrict collaboration to only existing
> > committers. That would prevent others from participating and earning
> > the merit to become committers, and that's not something we should be
> > doing. Anything that is okay to share with existing committers should
> > be okay to share to other potential contributors who want to
> > participate, and should be done in a space that allows them to do
> > that. The website is a perfect space for that, and has everything we
> > need. I'm actually not sure about Confluence... I suspect
> > non-committers wouldn't be able to participate there because they
> > probably can't get accounts for it.
> >
> >
> > > looks like we need to
> > > wait for INFRA to fix Confluence. I'd be curious how much we need to use
> > > the mailing list during
> > > the design phase. We can announce meeting dates/times on the mailing list
> > > and post links to
> > > meeting notes in Confluence. Ultimately, decisions made by the people
> > that
> > > want to be involved
> > > will turn into pull requests against the codebase which comitters can
> > weigh
> > > in on. When you say,
> > > "... but decisions about those would still need to be done on the mailing
> > > list." Are you saying that
> > > we need to discuss every single design decision on the mailing list?
> >
> > Yes and no. I am saying that decisions need to happen on the mailing
> > list, but I agree with you that this can be satisfied through pull
> > requests. I just wanted to emphasize that regardless of where we do
> > that pre-decision collaboration, that collaboration should not be
> > misconstrued as a decision to accept those ideas into the project. The
> > decision occurs during the PR or other activity that interfaces with
> > the mailing list, subsequent to the collaboration in the design/idea
> > phase.
> >
> > As for the pre-decision collaboration space we're discussing, I just
> > want to be careful that we're not creating such a space in an
> > exclusionary way that allows only existing committers to participate,
> > that excludes other potential contributors. This is still an
> > openly-developed project, and we should collaborate in a space that is
> > not exclusive to existing committers, but open to non-committer
> > contributors and potential contributors as well. So, while we may want
> > to keep a line separating dev activity from user consumption (an
> > important separation that relates to official ASF releases), we should
> > not be drawing a line between committer-devs as "internal" and
> > contributor-devs as "external". The website, with its own issue
> > tracker, the ability to render markdown, do reviews, and
> > collaboratively edit, seems like the ideal place to me. We've used it
> > before for the same purpose, and I think we should continue to do so.
> >
> >
> > >
> > > On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org> wrote:
> > >
> > > > So, I agree a space would be helpful. Although it's old school and
> > > > inconvenient, the mailing list is the canonical place for discussion.
> > > > We currently use GitHub issues a lot, but that's copied to a mailing
> > > > list (as is our old JIRA space), so if people want to participate
> > > > without a GitHub account, they can still do that. There are certain
> > > > options that are perhaps less convenient, such as just using the
> > > > mailing list and our dev SVN space, but still more appropriate than
> > > > options that would be less ubiquitous for potential participants.
> > > >
> > > > I think the ASF Confluence is probably fine, for storing, editing, and
> > > > collaborating on shared documents, but decisions about those would
> > > > still need to be done on the mailing list. If I remember correctly, we
> > > > used to have a Wiki space, prior to it being transferred to
> > > > Confluence, but it was poorly maintained, so we abandoned it in favor
> > > > of using the website for docs. I could be mis-remembering, but I think
> > > > this is the case. It might explain why you can't create a Confluence
> > > > space.
> > > >
> > > > My preference would be to just use the website. I think it's fine to
> > > > have a dev / design area of the website, and we can discuss on GitHub
> > > > issues for the accumulo-website repo. That is a bit less convenient
> > > > than Confluence if it's used heavily, but it's more convenient in the
> > > > sense that it's more accessible and fits more in line with our current
> > > > mode of operation. Plus, when a document is final, it's easy to link
> > > > to from our documentation, without making users jump to another
> > > > service to view docs.
> > > >
> > > > I would be opposed to using GitHub wiki or a new git repo. We have
> > > > enough repos. Although it seems like they are free, there is still a
> > > > lot of boilerplate work to maintain them, from managing
> > > > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > > > README, to keeping copyright dates updated in the NOTICE file, and
> > > > more.
> > > >
> > > > In summary, my preference:
> > > >
> > > > 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> > > > list (strongly preferred)
> > > > 2. Confluence, discuss on mailing list (prefer over other options, but
> > > > not a fan)
> > > > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use
> > this
> > > > option)
> > > > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > > > prefer not to use this option)
> > > >
> > > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org>
> > wrote:
> > > > >
> > > > > Currently, asf cannot create new wiki's because of a Confluence
> > issue (
> > > > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with
> > infra
> > > > and in response they created that issue.
> > > > >
> > > > > To expand on this discussion, I would like to toss out another
> > > > alternative to discuss / explore. What if we used a separate GitHub
> > > > project, something like Accumulo-Design, just like accumulo-proxy and
> > > > accumulo-examples. As a separate project, it would be available for
> > > > collaboration for the community, but remain separate from main project
> > and
> > > > the website to keep current code / documentation / design clearly
> > separate
> > > > from speculative design discussions. As a project:
> > > > >
> > > > > - document history would be preserved with git commit history.
> > > > > - document collaboration could be done with normal PR submissions /
> > > > reviews.
> > > > > - issues could be used to discuss design aspects, capturing the
> > comment
> > > > history.
> > > > >
> > > > > The biggest downside is that it would be yet another project to
> > follow /
> > > > track.
> > > > >
> > > > > For me, I think the issue is that we need a public, collaborative
> > space
> > > > to hold design discussions. Neither the main project or the web-site
> > seem
> > > > quite appropriate and Confluence seems to lack the collaboration that
> > can
> > > > be achieved with github.
> > > > >
> > > > > We need a space to capture the redesign and whatever we select can be
> > > > made to work - I'm just wondering what provides the easiest forum to
> > build
> > > > a collaborative space for the Accumulo community.
> > > > >
> > > > > Ed Coleman
> > > > >
> > > > >
> > > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > > Circling back on this issue - I agree that comments and such make
> > > > sense for internal design documents. I'm going to create an INFRA
> > ticket
> > > > for a cwiki space for Accumulo unless there are any objections.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Drew Farris <dr...@ill.org>
> > > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > > To: dev@accumulo.apache.org
> > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > >
> > > > > > As mentioned, wikis can provide a streamlined collaborative editing
> > > > workflow that's less labor intensive than updating a website. They can
> > > > promote collaboration by providing specific tooling to support
> > comments,
> > > > revisions and iteration.
> > > > > >
> > > > > > In terms of preservation, GH wikis act just like any other Git
> > > > repository, with a remote at (for example) git@github.com:
> > > > apache/accumulo.wiki.git
> > > > > > IIRC the pages are just GH flavored markdown. There are at least a
> > few
> > > > Apache projects using them.
> > > > > >
> > > > > > However, GH wikis lack some features that I feel are important to
> > > > support collaborative authoring. For example, the ability to comment
> > and
> > > > discuss specific passages in a document is a feature that's present in
> > > > Cwiki, but not in GH wikis. I've come appreciate this this in my google
> > > > docs and office workflows, so expect that it would be useful for
> > Accumulo
> > > > design discussions too.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > I would like to try a wiki for design documents, I think it
> > would be
> > > > > > > less cumbersome than the website and we can always link from the
> > > > > > > website and issues to the wiki. I think its ok to give it a try
> > and
> > > > > > > abandon it in the future, if abandoned would just need to
> > properly
> > > > > > > communicate that. The content should be archived in Apache
> > > > > > > infrastructure, so if GH wiki does not do that then we should
> > not use
> > > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > > >
> > > > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > > > > > >
> > > > > > > > I reverted the change. I didn't think it would be a big deal,
> > but
> > > > if
> > > > > > > > it
> > > > > > > requires discussion, then let's discuss it.
> > > > > > > >
> > > > > > > > I'm looking for a place to host information related to internal
> > > > > > > > design
> > > > > > > discussions. I envision these to be living documents that will be
> > > > > > > updated over time as the design/implementation progresses and
> > that
> > > > > > > other committers will be able to comment on and edit. I don't
> > feel
> > > > > > > that the website is the correct place for this because:
> > > > > > > >
> > > > > > > > 1. I don't think internal design discussions should go on the
> > > > > > > > project
> > > > > > > website.
> > > > > > > > 2. Changes to the design documents could not be seen by
> > others
> > > > > > > > right
> > > > > > > away (IIRC changes to the website are built and available at
> > > > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > > >
> > > > > > > > I looked in the INFRA issues and other projects are using the
> > GH
> > > > > > > > Wiki
> > > > > > > feature and I saw no mention of backing it up or the requirement
> > to
> > > > do
> > > > > > > so (maybe they rely on GitHub backing it up?). It does appear
> > that we
> > > > > > > would need an INFRA ticket so that they can modify the GitHub
> > project
> > > > > > > settings to lock the GitHub wiki down so that only committers can
> > > > > > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > > > > > Confluence (
> > > > > > > https://cwiki.apache.org) might be an acceptable alternative.
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > > Subject: Re: [accumulo] branch main updated: Enable Github
> > wiki in
> > > > > > > asf.yaml
> > > > > > > >
> > > > > > > > I don't recall a discussion about this change, but I think it
> > goes
> > > > > > > against previous efforts to make the website the one canonical
> > > > > > > location for our documentation. I don't even think infra is
> > backing
> > > > up
> > > > > > > wiki repos, so there wouldn't even be a record of the wiki
> > contents
> > > > in
> > > > > > > ASF spaces (vs. the main repo, which is backed up to GitBox and
> > the
> > > > > > > issue tracker, which CCs the notifications list).
> > > > > > > >
> > > > > > > > In short, I think this should be reverted and we should not
> > use the
> > > > > > > GitHub wiki. If we need to store documents in a version
> > controlled
> > > > > > > way, we can store them on the website, or in our project's SVN
> > dev
> > > > > > > space. The wiki is just another place people would have to
> > follow if
> > > > > > > they want to participate, and I don't think that serves us.
> > > > Therefore,
> > > > > > > I think we shouldn't use it.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > > > >
> > > > > > > > > This is an automated email from the ASF dual-hosted git
> > > > repository.
> > > > > > > > >
> > > > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The following commit(s) were added to refs/heads/main by this
> > > > push:
> > > > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml
> > ae8a817e7b is
> > > > > > > > > described below
> > > > > > > > >
> > > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > > >
> > > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > > ---
> > > > > > > > > .asf.yaml | 2 +-
> > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> > bc2c943e82..08aa357082
> > > > > > > > > 100644
> > > > > > > > > --- a/.asf.yaml
> > > > > > > > > +++ b/.asf.yaml
> > > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > > - big-data
> > > > > > > > > - hacktoberfest
> > > > > > > > > features:
> > > > > > > > > - wiki: false
> > > > > > > > > + wiki: true
> > > > > > > > > issues: true
> > > > > > > > > projects: true
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> >
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
I don't see the website as an area where we would have collaborative
discussions about an idea. For example, making comments and suggestions on
a document like you can do in Google Docs. I see the website as a place
where items are documented for user consumption after everything has been
finalized. I'm not trying to create a private discussion area, I think
anyone can see the wiki (but I think anonymous comments are disabled due to
spam issues). I see no issue with putting work-in-progress documents on a
wiki and referencing them via emails to the dev list. I think this is done
in a lot of other projects. Non-committers that don't have access to the
wiki and want to make comments, suggestions, and ask questions can do so
via the mailing list. I think it's also possible that people can get
confluence accounts (see https://issues.apache.org/jira/browse/INFRA-7058),
so if a non-committer wanted to participate they could.
On Thu, Mar 2, 2023 at 2:53 PM Christopher <ct...@apache.org> wrote:
> On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com> wrote:
> >
> > I'm opposed to using the website for the reasons I specified earlier, so
> it
>
> Your reasons that I saw were:
>
> > 1. I don't think internal design discussions should go on the project
> website.
>
> That doesn't look to me like a reason. That appears to just be stating
> the conclusion. Did I miss your reason here?
>
> > 2. Changes to the design documents could not be seen by others right
> away (IIRC changes to the website are built and available at
> https://accumulo.staged.apache.org/, but human intervention is required
> to publish it at https://accumulo.apache.org/).
>
> What do you mean by "others" here? Do you mean "users", as opposed to
> "developers/contributors"? The ASF draws a distinction between
> "developers/contributors" and "users" as it pertains to official
> releases. Releases are intended to be consumed by users, and
> pre-release stuff is intended to be collaborative, open to all
> potential developers/contributors. Very very rarely are things
> reserved exclusively for committers. We don't even have a private
> committers space (the private mailing list is PMC-private, not
> committer-private). Having a distinction between users and developers
> doesn't mean we can't publish things on the website... it just means
> that we should be careful about how we do it, which is the same care
> we should take regardless of where we put it. Specifically, the care
> we need to take is to avoid marketing pre-release content to users.
> One way we can exercise this care for content on our website is that
> we can avoid sharing these unpolished designs by simply not linking
> them on the site, or by placing them in an area that is clearly marked
> as intended for devs. But, we have no similar distinction between
> committers and non-committer devs for which we should avoid sharing
> pre-release content under development. In fact, it is the opposite...
> we should be developing openly so as to allow room for non-committers
> to become committers through participation in development activities.
>
> As for the staging/publication of the website, that's just a mechanic
> for verifying the website isn't broken before we serve it. It's not a
> mechanism for keeping things internal vs. shared and doesn't have
> anything to do with the separation between devs and users. We already
> publish Draft contents to the website, as well as developer-specific
> documentation not intended for users.
>
> We've even specifically published work-in-progress design documents
> there, of the same type that seems to be the basis of this
> conversation (https://accumulo.apache.org/design/system-snapshot). I
> would strongly prefer us to continue to do it this way, rather than
> create a new space, and have these kinds of things scattered in
> multiple places.
>
> If, on the other hand, you intend to say that these should be private
> because they aren't ready for other potential contributors, then I
> would argue that we're an openly developed project... if something
> isn't ready to be shared with other potential contributors /
> developers, such that you want to keep it internal to existing
> committers, then it's not ready to be contributed to the project at
> all... because we don't restrict collaboration to only existing
> committers. That would prevent others from participating and earning
> the merit to become committers, and that's not something we should be
> doing. Anything that is okay to share with existing committers should
> be okay to share to other potential contributors who want to
> participate, and should be done in a space that allows them to do
> that. The website is a perfect space for that, and has everything we
> need. I'm actually not sure about Confluence... I suspect
> non-committers wouldn't be able to participate there because they
> probably can't get accounts for it.
>
>
> > looks like we need to
> > wait for INFRA to fix Confluence. I'd be curious how much we need to use
> > the mailing list during
> > the design phase. We can announce meeting dates/times on the mailing list
> > and post links to
> > meeting notes in Confluence. Ultimately, decisions made by the people
> that
> > want to be involved
> > will turn into pull requests against the codebase which comitters can
> weigh
> > in on. When you say,
> > "... but decisions about those would still need to be done on the mailing
> > list." Are you saying that
> > we need to discuss every single design decision on the mailing list?
>
> Yes and no. I am saying that decisions need to happen on the mailing
> list, but I agree with you that this can be satisfied through pull
> requests. I just wanted to emphasize that regardless of where we do
> that pre-decision collaboration, that collaboration should not be
> misconstrued as a decision to accept those ideas into the project. The
> decision occurs during the PR or other activity that interfaces with
> the mailing list, subsequent to the collaboration in the design/idea
> phase.
>
> As for the pre-decision collaboration space we're discussing, I just
> want to be careful that we're not creating such a space in an
> exclusionary way that allows only existing committers to participate,
> that excludes other potential contributors. This is still an
> openly-developed project, and we should collaborate in a space that is
> not exclusive to existing committers, but open to non-committer
> contributors and potential contributors as well. So, while we may want
> to keep a line separating dev activity from user consumption (an
> important separation that relates to official ASF releases), we should
> not be drawing a line between committer-devs as "internal" and
> contributor-devs as "external". The website, with its own issue
> tracker, the ability to render markdown, do reviews, and
> collaboratively edit, seems like the ideal place to me. We've used it
> before for the same purpose, and I think we should continue to do so.
>
>
> >
> > On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org> wrote:
> >
> > > So, I agree a space would be helpful. Although it's old school and
> > > inconvenient, the mailing list is the canonical place for discussion.
> > > We currently use GitHub issues a lot, but that's copied to a mailing
> > > list (as is our old JIRA space), so if people want to participate
> > > without a GitHub account, they can still do that. There are certain
> > > options that are perhaps less convenient, such as just using the
> > > mailing list and our dev SVN space, but still more appropriate than
> > > options that would be less ubiquitous for potential participants.
> > >
> > > I think the ASF Confluence is probably fine, for storing, editing, and
> > > collaborating on shared documents, but decisions about those would
> > > still need to be done on the mailing list. If I remember correctly, we
> > > used to have a Wiki space, prior to it being transferred to
> > > Confluence, but it was poorly maintained, so we abandoned it in favor
> > > of using the website for docs. I could be mis-remembering, but I think
> > > this is the case. It might explain why you can't create a Confluence
> > > space.
> > >
> > > My preference would be to just use the website. I think it's fine to
> > > have a dev / design area of the website, and we can discuss on GitHub
> > > issues for the accumulo-website repo. That is a bit less convenient
> > > than Confluence if it's used heavily, but it's more convenient in the
> > > sense that it's more accessible and fits more in line with our current
> > > mode of operation. Plus, when a document is final, it's easy to link
> > > to from our documentation, without making users jump to another
> > > service to view docs.
> > >
> > > I would be opposed to using GitHub wiki or a new git repo. We have
> > > enough repos. Although it seems like they are free, there is still a
> > > lot of boilerplate work to maintain them, from managing
> > > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > > README, to keeping copyright dates updated in the NOTICE file, and
> > > more.
> > >
> > > In summary, my preference:
> > >
> > > 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> > > list (strongly preferred)
> > > 2. Confluence, discuss on mailing list (prefer over other options, but
> > > not a fan)
> > > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use
> this
> > > option)
> > > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > > prefer not to use this option)
> > >
> > > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org>
> wrote:
> > > >
> > > > Currently, asf cannot create new wiki's because of a Confluence
> issue (
> > > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with
> infra
> > > and in response they created that issue.
> > > >
> > > > To expand on this discussion, I would like to toss out another
> > > alternative to discuss / explore. What if we used a separate GitHub
> > > project, something like Accumulo-Design, just like accumulo-proxy and
> > > accumulo-examples. As a separate project, it would be available for
> > > collaboration for the community, but remain separate from main project
> and
> > > the website to keep current code / documentation / design clearly
> separate
> > > from speculative design discussions. As a project:
> > > >
> > > > - document history would be preserved with git commit history.
> > > > - document collaboration could be done with normal PR submissions /
> > > reviews.
> > > > - issues could be used to discuss design aspects, capturing the
> comment
> > > history.
> > > >
> > > > The biggest downside is that it would be yet another project to
> follow /
> > > track.
> > > >
> > > > For me, I think the issue is that we need a public, collaborative
> space
> > > to hold design discussions. Neither the main project or the web-site
> seem
> > > quite appropriate and Confluence seems to lack the collaboration that
> can
> > > be achieved with github.
> > > >
> > > > We need a space to capture the redesign and whatever we select can be
> > > made to work - I'm just wondering what provides the easiest forum to
> build
> > > a collaborative space for the Accumulo community.
> > > >
> > > > Ed Coleman
> > > >
> > > >
> > > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > > Circling back on this issue - I agree that comments and such make
> > > sense for internal design documents. I'm going to create an INFRA
> ticket
> > > for a cwiki space for Accumulo unless there are any objections.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Drew Farris <dr...@ill.org>
> > > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > > To: dev@accumulo.apache.org
> > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >
> > > > > As mentioned, wikis can provide a streamlined collaborative editing
> > > workflow that's less labor intensive than updating a website. They can
> > > promote collaboration by providing specific tooling to support
> comments,
> > > revisions and iteration.
> > > > >
> > > > > In terms of preservation, GH wikis act just like any other Git
> > > repository, with a remote at (for example) git@github.com:
> > > apache/accumulo.wiki.git
> > > > > IIRC the pages are just GH flavored markdown. There are at least a
> few
> > > Apache projects using them.
> > > > >
> > > > > However, GH wikis lack some features that I feel are important to
> > > support collaborative authoring. For example, the ability to comment
> and
> > > discuss specific passages in a document is a feature that's present in
> > > Cwiki, but not in GH wikis. I've come appreciate this this in my google
> > > docs and office workflows, so expect that it would be useful for
> Accumulo
> > > design discussions too.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org>
> > > wrote:
> > > > >
> > > > > > I would like to try a wiki for design documents, I think it
> would be
> > > > > > less cumbersome than the website and we can always link from the
> > > > > > website and issues to the wiki. I think its ok to give it a try
> and
> > > > > > abandon it in the future, if abandoned would just need to
> properly
> > > > > > communicate that. The content should be archived in Apache
> > > > > > infrastructure, so if GH wiki does not do that then we should
> not use
> > > > > > it. If GH wiki is not an option then could try cwiki.
> > > > > >
> > > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > > > > >
> > > > > > > I reverted the change. I didn't think it would be a big deal,
> but
> > > if
> > > > > > > it
> > > > > > requires discussion, then let's discuss it.
> > > > > > >
> > > > > > > I'm looking for a place to host information related to internal
> > > > > > > design
> > > > > > discussions. I envision these to be living documents that will be
> > > > > > updated over time as the design/implementation progresses and
> that
> > > > > > other committers will be able to comment on and edit. I don't
> feel
> > > > > > that the website is the correct place for this because:
> > > > > > >
> > > > > > > 1. I don't think internal design discussions should go on the
> > > > > > > project
> > > > > > website.
> > > > > > > 2. Changes to the design documents could not be seen by
> others
> > > > > > > right
> > > > > > away (IIRC changes to the website are built and available at
> > > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > > > required to publish it at https://accumulo.apache.org/).
> > > > > > >
> > > > > > > I looked in the INFRA issues and other projects are using the
> GH
> > > > > > > Wiki
> > > > > > feature and I saw no mention of backing it up or the requirement
> to
> > > do
> > > > > > so (maybe they rely on GitHub backing it up?). It does appear
> that we
> > > > > > would need an INFRA ticket so that they can modify the GitHub
> project
> > > > > > settings to lock the GitHub wiki down so that only committers can
> > > > > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > > > > Confluence (
> > > > > > https://cwiki.apache.org) might be an acceptable alternative.
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Christopher <ct...@apache.org>
> > > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > > Cc: commits@accumulo.apache.org
> > > > > > > Subject: Re: [accumulo] branch main updated: Enable Github
> wiki in
> > > > > > asf.yaml
> > > > > > >
> > > > > > > I don't recall a discussion about this change, but I think it
> goes
> > > > > > against previous efforts to make the website the one canonical
> > > > > > location for our documentation. I don't even think infra is
> backing
> > > up
> > > > > > wiki repos, so there wouldn't even be a record of the wiki
> contents
> > > in
> > > > > > ASF spaces (vs. the main repo, which is backed up to GitBox and
> the
> > > > > > issue tracker, which CCs the notifications list).
> > > > > > >
> > > > > > > In short, I think this should be reverted and we should not
> use the
> > > > > > GitHub wiki. If we need to store documents in a version
> controlled
> > > > > > way, we can store them on the website, or in our project's SVN
> dev
> > > > > > space. The wiki is just another place people would have to
> follow if
> > > > > > they want to participate, and I don't think that serves us.
> > > Therefore,
> > > > > > I think we shouldn't use it.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > > >
> > > > > > > > This is an automated email from the ASF dual-hosted git
> > > repository.
> > > > > > > >
> > > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > > >
> > > > > > > >
> > > > > > > > The following commit(s) were added to refs/heads/main by this
> > > push:
> > > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml
> ae8a817e7b is
> > > > > > > > described below
> > > > > > > >
> > > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > > >
> > > > > > > > Enable Github wiki in asf.yaml
> > > > > > > > ---
> > > > > > > > .asf.yaml | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/.asf.yaml b/.asf.yaml index
> bc2c943e82..08aa357082
> > > > > > > > 100644
> > > > > > > > --- a/.asf.yaml
> > > > > > > > +++ b/.asf.yaml
> > > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > > - big-data
> > > > > > > > - hacktoberfest
> > > > > > > > features:
> > > > > > > > - wiki: false
> > > > > > > > + wiki: true
> > > > > > > > issues: true
> > > > > > > > projects: true
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
On Thu, Mar 2, 2023 at 1:34 PM Dave Marion <dm...@gmail.com> wrote:
>
> I'm opposed to using the website for the reasons I specified earlier, so it
Your reasons that I saw were:
> 1. I don't think internal design discussions should go on the project website.
That doesn't look to me like a reason. That appears to just be stating
the conclusion. Did I miss your reason here?
> 2. Changes to the design documents could not be seen by others right away (IIRC changes to the website are built and available at https://accumulo.staged.apache.org/, but human intervention is required to publish it at https://accumulo.apache.org/).
What do you mean by "others" here? Do you mean "users", as opposed to
"developers/contributors"? The ASF draws a distinction between
"developers/contributors" and "users" as it pertains to official
releases. Releases are intended to be consumed by users, and
pre-release stuff is intended to be collaborative, open to all
potential developers/contributors. Very very rarely are things
reserved exclusively for committers. We don't even have a private
committers space (the private mailing list is PMC-private, not
committer-private). Having a distinction between users and developers
doesn't mean we can't publish things on the website... it just means
that we should be careful about how we do it, which is the same care
we should take regardless of where we put it. Specifically, the care
we need to take is to avoid marketing pre-release content to users.
One way we can exercise this care for content on our website is that
we can avoid sharing these unpolished designs by simply not linking
them on the site, or by placing them in an area that is clearly marked
as intended for devs. But, we have no similar distinction between
committers and non-committer devs for which we should avoid sharing
pre-release content under development. In fact, it is the opposite...
we should be developing openly so as to allow room for non-committers
to become committers through participation in development activities.
As for the staging/publication of the website, that's just a mechanic
for verifying the website isn't broken before we serve it. It's not a
mechanism for keeping things internal vs. shared and doesn't have
anything to do with the separation between devs and users. We already
publish Draft contents to the website, as well as developer-specific
documentation not intended for users.
We've even specifically published work-in-progress design documents
there, of the same type that seems to be the basis of this
conversation (https://accumulo.apache.org/design/system-snapshot). I
would strongly prefer us to continue to do it this way, rather than
create a new space, and have these kinds of things scattered in
multiple places.
If, on the other hand, you intend to say that these should be private
because they aren't ready for other potential contributors, then I
would argue that we're an openly developed project... if something
isn't ready to be shared with other potential contributors /
developers, such that you want to keep it internal to existing
committers, then it's not ready to be contributed to the project at
all... because we don't restrict collaboration to only existing
committers. That would prevent others from participating and earning
the merit to become committers, and that's not something we should be
doing. Anything that is okay to share with existing committers should
be okay to share to other potential contributors who want to
participate, and should be done in a space that allows them to do
that. The website is a perfect space for that, and has everything we
need. I'm actually not sure about Confluence... I suspect
non-committers wouldn't be able to participate there because they
probably can't get accounts for it.
> looks like we need to
> wait for INFRA to fix Confluence. I'd be curious how much we need to use
> the mailing list during
> the design phase. We can announce meeting dates/times on the mailing list
> and post links to
> meeting notes in Confluence. Ultimately, decisions made by the people that
> want to be involved
> will turn into pull requests against the codebase which comitters can weigh
> in on. When you say,
> "... but decisions about those would still need to be done on the mailing
> list." Are you saying that
> we need to discuss every single design decision on the mailing list?
Yes and no. I am saying that decisions need to happen on the mailing
list, but I agree with you that this can be satisfied through pull
requests. I just wanted to emphasize that regardless of where we do
that pre-decision collaboration, that collaboration should not be
misconstrued as a decision to accept those ideas into the project. The
decision occurs during the PR or other activity that interfaces with
the mailing list, subsequent to the collaboration in the design/idea
phase.
As for the pre-decision collaboration space we're discussing, I just
want to be careful that we're not creating such a space in an
exclusionary way that allows only existing committers to participate,
that excludes other potential contributors. This is still an
openly-developed project, and we should collaborate in a space that is
not exclusive to existing committers, but open to non-committer
contributors and potential contributors as well. So, while we may want
to keep a line separating dev activity from user consumption (an
important separation that relates to official ASF releases), we should
not be drawing a line between committer-devs as "internal" and
contributor-devs as "external". The website, with its own issue
tracker, the ability to render markdown, do reviews, and
collaboratively edit, seems like the ideal place to me. We've used it
before for the same purpose, and I think we should continue to do so.
>
> On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org> wrote:
>
> > So, I agree a space would be helpful. Although it's old school and
> > inconvenient, the mailing list is the canonical place for discussion.
> > We currently use GitHub issues a lot, but that's copied to a mailing
> > list (as is our old JIRA space), so if people want to participate
> > without a GitHub account, they can still do that. There are certain
> > options that are perhaps less convenient, such as just using the
> > mailing list and our dev SVN space, but still more appropriate than
> > options that would be less ubiquitous for potential participants.
> >
> > I think the ASF Confluence is probably fine, for storing, editing, and
> > collaborating on shared documents, but decisions about those would
> > still need to be done on the mailing list. If I remember correctly, we
> > used to have a Wiki space, prior to it being transferred to
> > Confluence, but it was poorly maintained, so we abandoned it in favor
> > of using the website for docs. I could be mis-remembering, but I think
> > this is the case. It might explain why you can't create a Confluence
> > space.
> >
> > My preference would be to just use the website. I think it's fine to
> > have a dev / design area of the website, and we can discuss on GitHub
> > issues for the accumulo-website repo. That is a bit less convenient
> > than Confluence if it's used heavily, but it's more convenient in the
> > sense that it's more accessible and fits more in line with our current
> > mode of operation. Plus, when a document is final, it's easy to link
> > to from our documentation, without making users jump to another
> > service to view docs.
> >
> > I would be opposed to using GitHub wiki or a new git repo. We have
> > enough repos. Although it seems like they are free, there is still a
> > lot of boilerplate work to maintain them, from managing
> > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > README, to keeping copyright dates updated in the NOTICE file, and
> > more.
> >
> > In summary, my preference:
> >
> > 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> > list (strongly preferred)
> > 2. Confluence, discuss on mailing list (prefer over other options, but
> > not a fan)
> > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use this
> > option)
> > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > prefer not to use this option)
> >
> > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org> wrote:
> > >
> > > Currently, asf cannot create new wiki's because of a Confluence issue (
> > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with infra
> > and in response they created that issue.
> > >
> > > To expand on this discussion, I would like to toss out another
> > alternative to discuss / explore. What if we used a separate GitHub
> > project, something like Accumulo-Design, just like accumulo-proxy and
> > accumulo-examples. As a separate project, it would be available for
> > collaboration for the community, but remain separate from main project and
> > the website to keep current code / documentation / design clearly separate
> > from speculative design discussions. As a project:
> > >
> > > - document history would be preserved with git commit history.
> > > - document collaboration could be done with normal PR submissions /
> > reviews.
> > > - issues could be used to discuss design aspects, capturing the comment
> > history.
> > >
> > > The biggest downside is that it would be yet another project to follow /
> > track.
> > >
> > > For me, I think the issue is that we need a public, collaborative space
> > to hold design discussions. Neither the main project or the web-site seem
> > quite appropriate and Confluence seems to lack the collaboration that can
> > be achieved with github.
> > >
> > > We need a space to capture the redesign and whatever we select can be
> > made to work - I'm just wondering what provides the easiest forum to build
> > a collaborative space for the Accumulo community.
> > >
> > > Ed Coleman
> > >
> > >
> > > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > > Circling back on this issue - I agree that comments and such make
> > sense for internal design documents. I'm going to create an INFRA ticket
> > for a cwiki space for Accumulo unless there are any objections.
> > > >
> > > > -----Original Message-----
> > > > From: Drew Farris <dr...@ill.org>
> > > > Sent: Saturday, February 25, 2023 5:16 PM
> > > > To: dev@accumulo.apache.org
> > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >
> > > > As mentioned, wikis can provide a streamlined collaborative editing
> > workflow that's less labor intensive than updating a website. They can
> > promote collaboration by providing specific tooling to support comments,
> > revisions and iteration.
> > > >
> > > > In terms of preservation, GH wikis act just like any other Git
> > repository, with a remote at (for example) git@github.com:
> > apache/accumulo.wiki.git
> > > > IIRC the pages are just GH flavored markdown. There are at least a few
> > Apache projects using them.
> > > >
> > > > However, GH wikis lack some features that I feel are important to
> > support collaborative authoring. For example, the ability to comment and
> > discuss specific passages in a document is a feature that's present in
> > Cwiki, but not in GH wikis. I've come appreciate this this in my google
> > docs and office workflows, so expect that it would be useful for Accumulo
> > design discussions too.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org>
> > wrote:
> > > >
> > > > > I would like to try a wiki for design documents, I think it would be
> > > > > less cumbersome than the website and we can always link from the
> > > > > website and issues to the wiki. I think its ok to give it a try and
> > > > > abandon it in the future, if abandoned would just need to properly
> > > > > communicate that. The content should be archived in Apache
> > > > > infrastructure, so if GH wiki does not do that then we should not use
> > > > > it. If GH wiki is not an option then could try cwiki.
> > > > >
> > > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > > > >
> > > > > > I reverted the change. I didn't think it would be a big deal, but
> > if
> > > > > > it
> > > > > requires discussion, then let's discuss it.
> > > > > >
> > > > > > I'm looking for a place to host information related to internal
> > > > > > design
> > > > > discussions. I envision these to be living documents that will be
> > > > > updated over time as the design/implementation progresses and that
> > > > > other committers will be able to comment on and edit. I don't feel
> > > > > that the website is the correct place for this because:
> > > > > >
> > > > > > 1. I don't think internal design discussions should go on the
> > > > > > project
> > > > > website.
> > > > > > 2. Changes to the design documents could not be seen by others
> > > > > > right
> > > > > away (IIRC changes to the website are built and available at
> > > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > > required to publish it at https://accumulo.apache.org/).
> > > > > >
> > > > > > I looked in the INFRA issues and other projects are using the GH
> > > > > > Wiki
> > > > > feature and I saw no mention of backing it up or the requirement to
> > do
> > > > > so (maybe they rely on GitHub backing it up?). It does appear that we
> > > > > would need an INFRA ticket so that they can modify the GitHub project
> > > > > settings to lock the GitHub wiki down so that only committers can
> > > > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > > > Confluence (
> > > > > https://cwiki.apache.org) might be an acceptable alternative.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christopher <ct...@apache.org>
> > > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > > Cc: commits@accumulo.apache.org
> > > > > > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> > > > > asf.yaml
> > > > > >
> > > > > > I don't recall a discussion about this change, but I think it goes
> > > > > against previous efforts to make the website the one canonical
> > > > > location for our documentation. I don't even think infra is backing
> > up
> > > > > wiki repos, so there wouldn't even be a record of the wiki contents
> > in
> > > > > ASF spaces (vs. the main repo, which is backed up to GitBox and the
> > > > > issue tracker, which CCs the notifications list).
> > > > > >
> > > > > > In short, I think this should be reverted and we should not use the
> > > > > GitHub wiki. If we need to store documents in a version controlled
> > > > > way, we can store them on the website, or in our project's SVN dev
> > > > > space. The wiki is just another place people would have to follow if
> > > > > they want to participate, and I don't think that serves us.
> > Therefore,
> > > > > I think we shouldn't use it.
> > > > > >
> > > > > >
> > > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > > >
> > > > > > > This is an automated email from the ASF dual-hosted git
> > repository.
> > > > > > >
> > > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > > >
> > > > > > >
> > > > > > > The following commit(s) were added to refs/heads/main by this
> > push:
> > > > > > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > > > > > described below
> > > > > > >
> > > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > > >
> > > > > > > Enable Github wiki in asf.yaml
> > > > > > > ---
> > > > > > > .asf.yaml | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > > > > > 100644
> > > > > > > --- a/.asf.yaml
> > > > > > > +++ b/.asf.yaml
> > > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > > - big-data
> > > > > > > - hacktoberfest
> > > > > > > features:
> > > > > > > - wiki: false
> > > > > > > + wiki: true
> > > > > > > issues: true
> > > > > > > projects: true
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> >
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Dave Marion <dm...@gmail.com>.
I'm opposed to using the website for the reasons I specified earlier, so it
looks like we need to
wait for INFRA to fix Confluence. I'd be curious how much we need to use
the mailing list during
the design phase. We can announce meeting dates/times on the mailing list
and post links to
meeting notes in Confluence. Ultimately, decisions made by the people that
want to be involved
will turn into pull requests against the codebase which comitters can weigh
in on. When you say,
"... but decisions about those would still need to be done on the mailing
list." Are you saying that
we need to discuss every single design decision on the mailing list?
On Thu, Mar 2, 2023 at 12:56 PM Christopher <ct...@apache.org> wrote:
> So, I agree a space would be helpful. Although it's old school and
> inconvenient, the mailing list is the canonical place for discussion.
> We currently use GitHub issues a lot, but that's copied to a mailing
> list (as is our old JIRA space), so if people want to participate
> without a GitHub account, they can still do that. There are certain
> options that are perhaps less convenient, such as just using the
> mailing list and our dev SVN space, but still more appropriate than
> options that would be less ubiquitous for potential participants.
>
> I think the ASF Confluence is probably fine, for storing, editing, and
> collaborating on shared documents, but decisions about those would
> still need to be done on the mailing list. If I remember correctly, we
> used to have a Wiki space, prior to it being transferred to
> Confluence, but it was poorly maintained, so we abandoned it in favor
> of using the website for docs. I could be mis-remembering, but I think
> this is the case. It might explain why you can't create a Confluence
> space.
>
> My preference would be to just use the website. I think it's fine to
> have a dev / design area of the website, and we can discuss on GitHub
> issues for the accumulo-website repo. That is a bit less convenient
> than Confluence if it's used heavily, but it's more convenient in the
> sense that it's more accessible and fits more in line with our current
> mode of operation. Plus, when a document is final, it's easy to link
> to from our documentation, without making users jump to another
> service to view docs.
>
> I would be opposed to using GitHub wiki or a new git repo. We have
> enough repos. Although it seems like they are free, there is still a
> lot of boilerplate work to maintain them, from managing
> .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> README, to keeping copyright dates updated in the NOTICE file, and
> more.
>
> In summary, my preference:
>
> 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> list (strongly preferred)
> 2. Confluence, discuss on mailing list (prefer over other options, but
> not a fan)
> 3. GitHub wiki, discuss on mailing list (strongly prefer not to use this
> option)
> 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> prefer not to use this option)
>
> On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org> wrote:
> >
> > Currently, asf cannot create new wiki's because of a Confluence issue (
> https://issues.apache.org/jira/browse/INFRA-24291) I chatted with infra
> and in response they created that issue.
> >
> > To expand on this discussion, I would like to toss out another
> alternative to discuss / explore. What if we used a separate GitHub
> project, something like Accumulo-Design, just like accumulo-proxy and
> accumulo-examples. As a separate project, it would be available for
> collaboration for the community, but remain separate from main project and
> the website to keep current code / documentation / design clearly separate
> from speculative design discussions. As a project:
> >
> > - document history would be preserved with git commit history.
> > - document collaboration could be done with normal PR submissions /
> reviews.
> > - issues could be used to discuss design aspects, capturing the comment
> history.
> >
> > The biggest downside is that it would be yet another project to follow /
> track.
> >
> > For me, I think the issue is that we need a public, collaborative space
> to hold design discussions. Neither the main project or the web-site seem
> quite appropriate and Confluence seems to lack the collaboration that can
> be achieved with github.
> >
> > We need a space to capture the redesign and whatever we select can be
> made to work - I'm just wondering what provides the easiest forum to build
> a collaborative space for the Accumulo community.
> >
> > Ed Coleman
> >
> >
> > On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > > Circling back on this issue - I agree that comments and such make
> sense for internal design documents. I'm going to create an INFRA ticket
> for a cwiki space for Accumulo unless there are any objections.
> > >
> > > -----Original Message-----
> > > From: Drew Farris <dr...@ill.org>
> > > Sent: Saturday, February 25, 2023 5:16 PM
> > > To: dev@accumulo.apache.org
> > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > >
> > > As mentioned, wikis can provide a streamlined collaborative editing
> workflow that's less labor intensive than updating a website. They can
> promote collaboration by providing specific tooling to support comments,
> revisions and iteration.
> > >
> > > In terms of preservation, GH wikis act just like any other Git
> repository, with a remote at (for example) git@github.com:
> apache/accumulo.wiki.git
> > > IIRC the pages are just GH flavored markdown. There are at least a few
> Apache projects using them.
> > >
> > > However, GH wikis lack some features that I feel are important to
> support collaborative authoring. For example, the ability to comment and
> discuss specific passages in a document is a feature that's present in
> Cwiki, but not in GH wikis. I've come appreciate this this in my google
> docs and office workflows, so expect that it would be useful for Accumulo
> design discussions too.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org>
> wrote:
> > >
> > > > I would like to try a wiki for design documents, I think it would be
> > > > less cumbersome than the website and we can always link from the
> > > > website and issues to the wiki. I think its ok to give it a try and
> > > > abandon it in the future, if abandoned would just need to properly
> > > > communicate that. The content should be archived in Apache
> > > > infrastructure, so if GH wiki does not do that then we should not use
> > > > it. If GH wiki is not an option then could try cwiki.
> > > >
> > > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > > >
> > > > > I reverted the change. I didn't think it would be a big deal, but
> if
> > > > > it
> > > > requires discussion, then let's discuss it.
> > > > >
> > > > > I'm looking for a place to host information related to internal
> > > > > design
> > > > discussions. I envision these to be living documents that will be
> > > > updated over time as the design/implementation progresses and that
> > > > other committers will be able to comment on and edit. I don't feel
> > > > that the website is the correct place for this because:
> > > > >
> > > > > 1. I don't think internal design discussions should go on the
> > > > > project
> > > > website.
> > > > > 2. Changes to the design documents could not be seen by others
> > > > > right
> > > > away (IIRC changes to the website are built and available at
> > > > https://accumulo.staged.apache.org/, but human intervention is
> > > > required to publish it at https://accumulo.apache.org/).
> > > > >
> > > > > I looked in the INFRA issues and other projects are using the GH
> > > > > Wiki
> > > > feature and I saw no mention of backing it up or the requirement to
> do
> > > > so (maybe they rely on GitHub backing it up?). It does appear that we
> > > > would need an INFRA ticket so that they can modify the GitHub project
> > > > settings to lock the GitHub wiki down so that only committers can
> > > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > > Confluence (
> > > > https://cwiki.apache.org) might be an acceptable alternative.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Christopher <ct...@apache.org>
> > > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > > Cc: commits@accumulo.apache.org
> > > > > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> > > > asf.yaml
> > > > >
> > > > > I don't recall a discussion about this change, but I think it goes
> > > > against previous efforts to make the website the one canonical
> > > > location for our documentation. I don't even think infra is backing
> up
> > > > wiki repos, so there wouldn't even be a record of the wiki contents
> in
> > > > ASF spaces (vs. the main repo, which is backed up to GitBox and the
> > > > issue tracker, which CCs the notifications list).
> > > > >
> > > > > In short, I think this should be reverted and we should not use the
> > > > GitHub wiki. If we need to store documents in a version controlled
> > > > way, we can store them on the website, or in our project's SVN dev
> > > > space. The wiki is just another place people would have to follow if
> > > > they want to participate, and I don't think that serves us.
> Therefore,
> > > > I think we shouldn't use it.
> > > > >
> > > > >
> > > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > > >
> > > > > > This is an automated email from the ASF dual-hosted git
> repository.
> > > > > >
> > > > > > dlmarion pushed a commit to branch main in repository
> > > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > > >
> > > > > >
> > > > > > The following commit(s) were added to refs/heads/main by this
> push:
> > > > > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > > > > described below
> > > > > >
> > > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > > Author: Dave Marion <dl...@apache.org>
> > > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > > >
> > > > > > Enable Github wiki in asf.yaml
> > > > > > ---
> > > > > > .asf.yaml | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > > > > 100644
> > > > > > --- a/.asf.yaml
> > > > > > +++ b/.asf.yaml
> > > > > > @@ -27,7 +27,7 @@ github:
> > > > > > - big-data
> > > > > > - hacktoberfest
> > > > > > features:
> > > > > > - wiki: false
> > > > > > + wiki: true
> > > > > > issues: true
> > > > > > projects: true
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Christopher <ct...@apache.org>.
So, I agree a space would be helpful. Although it's old school and
inconvenient, the mailing list is the canonical place for discussion.
We currently use GitHub issues a lot, but that's copied to a mailing
list (as is our old JIRA space), so if people want to participate
without a GitHub account, they can still do that. There are certain
options that are perhaps less convenient, such as just using the
mailing list and our dev SVN space, but still more appropriate than
options that would be less ubiquitous for potential participants.
I think the ASF Confluence is probably fine, for storing, editing, and
collaborating on shared documents, but decisions about those would
still need to be done on the mailing list. If I remember correctly, we
used to have a Wiki space, prior to it being transferred to
Confluence, but it was poorly maintained, so we abandoned it in favor
of using the website for docs. I could be mis-remembering, but I think
this is the case. It might explain why you can't create a Confluence
space.
My preference would be to just use the website. I think it's fine to
have a dev / design area of the website, and we can discuss on GitHub
issues for the accumulo-website repo. That is a bit less convenient
than Confluence if it's used heavily, but it's more convenient in the
sense that it's more accessible and fits more in line with our current
mode of operation. Plus, when a document is final, it's easy to link
to from our documentation, without making users jump to another
service to view docs.
I would be opposed to using GitHub wiki or a new git repo. We have
enough repos. Although it seems like they are free, there is still a
lot of boilerplate work to maintain them, from managing
.github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
README, to keeping copyright dates updated in the NOTICE file, and
more.
In summary, my preference:
1. Keep a space in accumulo-website, discuss on GH issues and mailing
list (strongly preferred)
2. Confluence, discuss on mailing list (prefer over other options, but
not a fan)
3. GitHub wiki, discuss on mailing list (strongly prefer not to use this option)
4. New GitHub repo, discuss on GH issues and mailing list (strongly
prefer not to use this option)
On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman <ed...@apache.org> wrote:
>
> Currently, asf cannot create new wiki's because of a Confluence issue (https://issues.apache.org/jira/browse/INFRA-24291) I chatted with infra and in response they created that issue.
>
> To expand on this discussion, I would like to toss out another alternative to discuss / explore. What if we used a separate GitHub project, something like Accumulo-Design, just like accumulo-proxy and accumulo-examples. As a separate project, it would be available for collaboration for the community, but remain separate from main project and the website to keep current code / documentation / design clearly separate from speculative design discussions. As a project:
>
> - document history would be preserved with git commit history.
> - document collaboration could be done with normal PR submissions / reviews.
> - issues could be used to discuss design aspects, capturing the comment history.
>
> The biggest downside is that it would be yet another project to follow / track.
>
> For me, I think the issue is that we need a public, collaborative space to hold design discussions. Neither the main project or the web-site seem quite appropriate and Confluence seems to lack the collaboration that can be achieved with github.
>
> We need a space to capture the redesign and whatever we select can be made to work - I'm just wondering what provides the easiest forum to build a collaborative space for the Accumulo community.
>
> Ed Coleman
>
>
> On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> > Circling back on this issue - I agree that comments and such make sense for internal design documents. I'm going to create an INFRA ticket for a cwiki space for Accumulo unless there are any objections.
> >
> > -----Original Message-----
> > From: Drew Farris <dr...@ill.org>
> > Sent: Saturday, February 25, 2023 5:16 PM
> > To: dev@accumulo.apache.org
> > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> >
> > As mentioned, wikis can provide a streamlined collaborative editing workflow that's less labor intensive than updating a website. They can promote collaboration by providing specific tooling to support comments, revisions and iteration.
> >
> > In terms of preservation, GH wikis act just like any other Git repository, with a remote at (for example) git@github.com:apache/accumulo.wiki.git
> > IIRC the pages are just GH flavored markdown. There are at least a few Apache projects using them.
> >
> > However, GH wikis lack some features that I feel are important to support collaborative authoring. For example, the ability to comment and discuss specific passages in a document is a feature that's present in Cwiki, but not in GH wikis. I've come appreciate this this in my google docs and office workflows, so expect that it would be useful for Accumulo design discussions too.
> >
> >
> >
> >
> >
> >
> > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org> wrote:
> >
> > > I would like to try a wiki for design documents, I think it would be
> > > less cumbersome than the website and we can always link from the
> > > website and issues to the wiki. I think its ok to give it a try and
> > > abandon it in the future, if abandoned would just need to properly
> > > communicate that. The content should be archived in Apache
> > > infrastructure, so if GH wiki does not do that then we should not use
> > > it. If GH wiki is not an option then could try cwiki.
> > >
> > > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > > >
> > > > I reverted the change. I didn't think it would be a big deal, but if
> > > > it
> > > requires discussion, then let's discuss it.
> > > >
> > > > I'm looking for a place to host information related to internal
> > > > design
> > > discussions. I envision these to be living documents that will be
> > > updated over time as the design/implementation progresses and that
> > > other committers will be able to comment on and edit. I don't feel
> > > that the website is the correct place for this because:
> > > >
> > > > 1. I don't think internal design discussions should go on the
> > > > project
> > > website.
> > > > 2. Changes to the design documents could not be seen by others
> > > > right
> > > away (IIRC changes to the website are built and available at
> > > https://accumulo.staged.apache.org/, but human intervention is
> > > required to publish it at https://accumulo.apache.org/).
> > > >
> > > > I looked in the INFRA issues and other projects are using the GH
> > > > Wiki
> > > feature and I saw no mention of backing it up or the requirement to do
> > > so (maybe they rely on GitHub backing it up?). It does appear that we
> > > would need an INFRA ticket so that they can modify the GitHub project
> > > settings to lock the GitHub wiki down so that only committers can
> > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > Confluence (
> > > https://cwiki.apache.org) might be an acceptable alternative.
> > > >
> > > > -----Original Message-----
> > > > From: Christopher <ct...@apache.org>
> > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > To: accumulo-dev <de...@accumulo.apache.org>
> > > > Cc: commits@accumulo.apache.org
> > > > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> > > asf.yaml
> > > >
> > > > I don't recall a discussion about this change, but I think it goes
> > > against previous efforts to make the website the one canonical
> > > location for our documentation. I don't even think infra is backing up
> > > wiki repos, so there wouldn't even be a record of the wiki contents in
> > > ASF spaces (vs. the main repo, which is backed up to GitBox and the
> > > issue tracker, which CCs the notifications list).
> > > >
> > > > In short, I think this should be reverted and we should not use the
> > > GitHub wiki. If we need to store documents in a version controlled
> > > way, we can store them on the website, or in our project's SVN dev
> > > space. The wiki is just another place people would have to follow if
> > > they want to participate, and I don't think that serves us. Therefore,
> > > I think we shouldn't use it.
> > > >
> > > >
> > > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > dlmarion pushed a commit to branch main in repository
> > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/main by this push:
> > > > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > > > described below
> > > > >
> > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > Author: Dave Marion <dl...@apache.org>
> > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > >
> > > > > Enable Github wiki in asf.yaml
> > > > > ---
> > > > > .asf.yaml | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > > > 100644
> > > > > --- a/.asf.yaml
> > > > > +++ b/.asf.yaml
> > > > > @@ -27,7 +27,7 @@ github:
> > > > > - big-data
> > > > > - hacktoberfest
> > > > > features:
> > > > > - wiki: false
> > > > > + wiki: true
> > > > > issues: true
> > > > > projects: true
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
RE: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Ed Coleman <ed...@apache.org>.
Currently, asf cannot create new wiki's because of a Confluence issue (https://issues.apache.org/jira/browse/INFRA-24291) I chatted with infra and in response they created that issue.
To expand on this discussion, I would like to toss out another alternative to discuss / explore. What if we used a separate GitHub project, something like Accumulo-Design, just like accumulo-proxy and accumulo-examples. As a separate project, it would be available for collaboration for the community, but remain separate from main project and the website to keep current code / documentation / design clearly separate from speculative design discussions. As a project:
- document history would be preserved with git commit history.
- document collaboration could be done with normal PR submissions / reviews.
- issues could be used to discuss design aspects, capturing the comment history.
The biggest downside is that it would be yet another project to follow / track.
For me, I think the issue is that we need a public, collaborative space to hold design discussions. Neither the main project or the web-site seem quite appropriate and Confluence seems to lack the collaboration that can be achieved with github.
We need a space to capture the redesign and whatever we select can be made to work - I'm just wondering what provides the easiest forum to build a collaborative space for the Accumulo community.
Ed Coleman
On 2023/02/28 16:35:31 dlmarion@comcast.net wrote:
> Circling back on this issue - I agree that comments and such make sense for internal design documents. I'm going to create an INFRA ticket for a cwiki space for Accumulo unless there are any objections.
>
> -----Original Message-----
> From: Drew Farris <dr...@ill.org>
> Sent: Saturday, February 25, 2023 5:16 PM
> To: dev@accumulo.apache.org
> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
>
> As mentioned, wikis can provide a streamlined collaborative editing workflow that's less labor intensive than updating a website. They can promote collaboration by providing specific tooling to support comments, revisions and iteration.
>
> In terms of preservation, GH wikis act just like any other Git repository, with a remote at (for example) git@github.com:apache/accumulo.wiki.git
> IIRC the pages are just GH flavored markdown. There are at least a few Apache projects using them.
>
> However, GH wikis lack some features that I feel are important to support collaborative authoring. For example, the ability to comment and discuss specific passages in a document is a feature that's present in Cwiki, but not in GH wikis. I've come appreciate this this in my google docs and office workflows, so expect that it would be useful for Accumulo design discussions too.
>
>
>
>
>
>
> On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org> wrote:
>
> > I would like to try a wiki for design documents, I think it would be
> > less cumbersome than the website and we can always link from the
> > website and issues to the wiki. I think its ok to give it a try and
> > abandon it in the future, if abandoned would just need to properly
> > communicate that. The content should be archived in Apache
> > infrastructure, so if GH wiki does not do that then we should not use
> > it. If GH wiki is not an option then could try cwiki.
> >
> > On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> > >
> > > I reverted the change. I didn't think it would be a big deal, but if
> > > it
> > requires discussion, then let's discuss it.
> > >
> > > I'm looking for a place to host information related to internal
> > > design
> > discussions. I envision these to be living documents that will be
> > updated over time as the design/implementation progresses and that
> > other committers will be able to comment on and edit. I don't feel
> > that the website is the correct place for this because:
> > >
> > > 1. I don't think internal design discussions should go on the
> > > project
> > website.
> > > 2. Changes to the design documents could not be seen by others
> > > right
> > away (IIRC changes to the website are built and available at
> > https://accumulo.staged.apache.org/, but human intervention is
> > required to publish it at https://accumulo.apache.org/).
> > >
> > > I looked in the INFRA issues and other projects are using the GH
> > > Wiki
> > feature and I saw no mention of backing it up or the requirement to do
> > so (maybe they rely on GitHub backing it up?). It does appear that we
> > would need an INFRA ticket so that they can modify the GitHub project
> > settings to lock the GitHub wiki down so that only committers can
> > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > Confluence (
> > https://cwiki.apache.org) might be an acceptable alternative.
> > >
> > > -----Original Message-----
> > > From: Christopher <ct...@apache.org>
> > > Sent: Saturday, February 25, 2023 4:41 AM
> > > To: accumulo-dev <de...@accumulo.apache.org>
> > > Cc: commits@accumulo.apache.org
> > > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> > asf.yaml
> > >
> > > I don't recall a discussion about this change, but I think it goes
> > against previous efforts to make the website the one canonical
> > location for our documentation. I don't even think infra is backing up
> > wiki repos, so there wouldn't even be a record of the wiki contents in
> > ASF spaces (vs. the main repo, which is backed up to GitBox and the
> > issue tracker, which CCs the notifications list).
> > >
> > > In short, I think this should be reverted and we should not use the
> > GitHub wiki. If we need to store documents in a version controlled
> > way, we can store them on the website, or in our project's SVN dev
> > space. The wiki is just another place people would have to follow if
> > they want to participate, and I don't think that serves us. Therefore,
> > I think we shouldn't use it.
> > >
> > >
> > > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > dlmarion pushed a commit to branch main in repository
> > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > >
> > > >
> > > > The following commit(s) were added to refs/heads/main by this push:
> > > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > > described below
> > > >
> > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > Author: Dave Marion <dl...@apache.org>
> > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > >
> > > > Enable Github wiki in asf.yaml
> > > > ---
> > > > .asf.yaml | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > > 100644
> > > > --- a/.asf.yaml
> > > > +++ b/.asf.yaml
> > > > @@ -27,7 +27,7 @@ github:
> > > > - big-data
> > > > - hacktoberfest
> > > > features:
> > > > - wiki: false
> > > > + wiki: true
> > > > issues: true
> > > > projects: true
> > > >
> > > >
> > > >
> > >
> >
>
>
RE: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by dl...@comcast.net.
Circling back on this issue - I agree that comments and such make sense for internal design documents. I'm going to create an INFRA ticket for a cwiki space for Accumulo unless there are any objections.
-----Original Message-----
From: Drew Farris <dr...@ill.org>
Sent: Saturday, February 25, 2023 5:16 PM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
As mentioned, wikis can provide a streamlined collaborative editing workflow that's less labor intensive than updating a website. They can promote collaboration by providing specific tooling to support comments, revisions and iteration.
In terms of preservation, GH wikis act just like any other Git repository, with a remote at (for example) git@github.com:apache/accumulo.wiki.git
IIRC the pages are just GH flavored markdown. There are at least a few Apache projects using them.
However, GH wikis lack some features that I feel are important to support collaborative authoring. For example, the ability to comment and discuss specific passages in a document is a feature that's present in Cwiki, but not in GH wikis. I've come appreciate this this in my google docs and office workflows, so expect that it would be useful for Accumulo design discussions too.
On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org> wrote:
> I would like to try a wiki for design documents, I think it would be
> less cumbersome than the website and we can always link from the
> website and issues to the wiki. I think its ok to give it a try and
> abandon it in the future, if abandoned would just need to properly
> communicate that. The content should be archived in Apache
> infrastructure, so if GH wiki does not do that then we should not use
> it. If GH wiki is not an option then could try cwiki.
>
> On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> >
> > I reverted the change. I didn't think it would be a big deal, but if
> > it
> requires discussion, then let's discuss it.
> >
> > I'm looking for a place to host information related to internal
> > design
> discussions. I envision these to be living documents that will be
> updated over time as the design/implementation progresses and that
> other committers will be able to comment on and edit. I don't feel
> that the website is the correct place for this because:
> >
> > 1. I don't think internal design discussions should go on the
> > project
> website.
> > 2. Changes to the design documents could not be seen by others
> > right
> away (IIRC changes to the website are built and available at
> https://accumulo.staged.apache.org/, but human intervention is
> required to publish it at https://accumulo.apache.org/).
> >
> > I looked in the INFRA issues and other projects are using the GH
> > Wiki
> feature and I saw no mention of backing it up or the requirement to do
> so (maybe they rely on GitHub backing it up?). It does appear that we
> would need an INFRA ticket so that they can modify the GitHub project
> settings to lock the GitHub wiki down so that only committers can
> modify it. If GitHub Wiki is not acceptable, then I think Apache
> Confluence (
> https://cwiki.apache.org) might be an acceptable alternative.
> >
> > -----Original Message-----
> > From: Christopher <ct...@apache.org>
> > Sent: Saturday, February 25, 2023 4:41 AM
> > To: accumulo-dev <de...@accumulo.apache.org>
> > Cc: commits@accumulo.apache.org
> > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> asf.yaml
> >
> > I don't recall a discussion about this change, but I think it goes
> against previous efforts to make the website the one canonical
> location for our documentation. I don't even think infra is backing up
> wiki repos, so there wouldn't even be a record of the wiki contents in
> ASF spaces (vs. the main repo, which is backed up to GitBox and the
> issue tracker, which CCs the notifications list).
> >
> > In short, I think this should be reverted and we should not use the
> GitHub wiki. If we need to store documents in a version controlled
> way, we can store them on the website, or in our project's SVN dev
> space. The wiki is just another place people would have to follow if
> they want to participate, and I don't think that serves us. Therefore,
> I think we shouldn't use it.
> >
> >
> > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > dlmarion pushed a commit to branch main in repository
> > > https://gitbox.apache.org/repos/asf/accumulo.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/main by this push:
> > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > described below
> > >
> > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > Author: Dave Marion <dl...@apache.org>
> > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > >
> > > Enable Github wiki in asf.yaml
> > > ---
> > > .asf.yaml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > 100644
> > > --- a/.asf.yaml
> > > +++ b/.asf.yaml
> > > @@ -27,7 +27,7 @@ github:
> > > - big-data
> > > - hacktoberfest
> > > features:
> > > - wiki: false
> > > + wiki: true
> > > issues: true
> > > projects: true
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Drew Farris <dr...@ill.org>.
As mentioned, wikis can provide a streamlined collaborative editing
workflow that's less labor intensive than updating a website. They can
promote collaboration by providing specific tooling to support comments,
revisions and iteration.
In terms of preservation, GH wikis act just like any other Git repository,
with a remote at (for example) git@github.com:apache/accumulo.wiki.git
IIRC the pages are just GH flavored markdown. There are at least a few
Apache projects using them.
However, GH wikis lack some features that I feel are important to support
collaborative authoring. For example, the ability to comment and discuss
specific passages in a document is a feature that's present in Cwiki, but
not in GH wikis. I've come appreciate this this in my google docs and office
workflows, so expect that it would be useful for Accumulo design
discussions
too.
On Sat, Feb 25, 2023 at 2:54 PM Keith Turner <kt...@apache.org> wrote:
> I would like to try a wiki for design documents, I think it would be
> less cumbersome than the website and we can always link from the
> website and issues to the wiki. I think its ok to give it a try and
> abandon it in the future, if abandoned would just need to properly
> communicate that. The content should be archived in Apache
> infrastructure, so if GH wiki does not do that then we should not use
> it. If GH wiki is not an option then could try cwiki.
>
> On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
> >
> > I reverted the change. I didn't think it would be a big deal, but if it
> requires discussion, then let's discuss it.
> >
> > I'm looking for a place to host information related to internal design
> discussions. I envision these to be living documents that will be updated
> over time as the design/implementation progresses and that other committers
> will be able to comment on and edit. I don't feel that the website is the
> correct place for this because:
> >
> > 1. I don't think internal design discussions should go on the project
> website.
> > 2. Changes to the design documents could not be seen by others right
> away (IIRC changes to the website are built and available at
> https://accumulo.staged.apache.org/, but human intervention is required
> to publish it at https://accumulo.apache.org/).
> >
> > I looked in the INFRA issues and other projects are using the GH Wiki
> feature and I saw no mention of backing it up or the requirement to do so
> (maybe they rely on GitHub backing it up?). It does appear that we would
> need an INFRA ticket so that they can modify the GitHub project settings to
> lock the GitHub wiki down so that only committers can modify it. If GitHub
> Wiki is not acceptable, then I think Apache Confluence (
> https://cwiki.apache.org) might be an acceptable alternative.
> >
> > -----Original Message-----
> > From: Christopher <ct...@apache.org>
> > Sent: Saturday, February 25, 2023 4:41 AM
> > To: accumulo-dev <de...@accumulo.apache.org>
> > Cc: commits@accumulo.apache.org
> > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> asf.yaml
> >
> > I don't recall a discussion about this change, but I think it goes
> against previous efforts to make the website the one canonical location for
> our documentation. I don't even think infra is backing up wiki repos, so
> there wouldn't even be a record of the wiki contents in ASF spaces (vs. the
> main repo, which is backed up to GitBox and the issue tracker, which CCs
> the notifications list).
> >
> > In short, I think this should be reverted and we should not use the
> GitHub wiki. If we need to store documents in a version controlled way, we
> can store them on the website, or in our project's SVN dev space. The wiki
> is just another place people would have to follow if they want to
> participate, and I don't think that serves us. Therefore, I think we
> shouldn't use it.
> >
> >
> > On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > dlmarion pushed a commit to branch main in repository
> > > https://gitbox.apache.org/repos/asf/accumulo.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/main by this push:
> > > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > described below
> > >
> > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > Author: Dave Marion <dl...@apache.org>
> > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > >
> > > Enable Github wiki in asf.yaml
> > > ---
> > > .asf.yaml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/.asf.yaml b/.asf.yaml
> > > index bc2c943e82..08aa357082 100644
> > > --- a/.asf.yaml
> > > +++ b/.asf.yaml
> > > @@ -27,7 +27,7 @@ github:
> > > - big-data
> > > - hacktoberfest
> > > features:
> > > - wiki: false
> > > + wiki: true
> > > issues: true
> > > projects: true
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Enable Github wiki in asf.yaml?
Posted by Keith Turner <kt...@apache.org>.
I would like to try a wiki for design documents, I think it would be
less cumbersome than the website and we can always link from the
website and issues to the wiki. I think its ok to give it a try and
abandon it in the future, if abandoned would just need to properly
communicate that. The content should be archived in Apache
infrastructure, so if GH wiki does not do that then we should not use
it. If GH wiki is not an option then could try cwiki.
On Sat, Feb 25, 2023 at 7:55 AM <dl...@comcast.net> wrote:
>
> I reverted the change. I didn't think it would be a big deal, but if it requires discussion, then let's discuss it.
>
> I'm looking for a place to host information related to internal design discussions. I envision these to be living documents that will be updated over time as the design/implementation progresses and that other committers will be able to comment on and edit. I don't feel that the website is the correct place for this because:
>
> 1. I don't think internal design discussions should go on the project website.
> 2. Changes to the design documents could not be seen by others right away (IIRC changes to the website are built and available at https://accumulo.staged.apache.org/, but human intervention is required to publish it at https://accumulo.apache.org/).
>
> I looked in the INFRA issues and other projects are using the GH Wiki feature and I saw no mention of backing it up or the requirement to do so (maybe they rely on GitHub backing it up?). It does appear that we would need an INFRA ticket so that they can modify the GitHub project settings to lock the GitHub wiki down so that only committers can modify it. If GitHub Wiki is not acceptable, then I think Apache Confluence (https://cwiki.apache.org) might be an acceptable alternative.
>
> -----Original Message-----
> From: Christopher <ct...@apache.org>
> Sent: Saturday, February 25, 2023 4:41 AM
> To: accumulo-dev <de...@accumulo.apache.org>
> Cc: commits@accumulo.apache.org
> Subject: Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml
>
> I don't recall a discussion about this change, but I think it goes against previous efforts to make the website the one canonical location for our documentation. I don't even think infra is backing up wiki repos, so there wouldn't even be a record of the wiki contents in ASF spaces (vs. the main repo, which is backed up to GitBox and the issue tracker, which CCs the notifications list).
>
> In short, I think this should be reverted and we should not use the GitHub wiki. If we need to store documents in a version controlled way, we can store them on the website, or in our project's SVN dev space. The wiki is just another place people would have to follow if they want to participate, and I don't think that serves us. Therefore, I think we shouldn't use it.
>
>
> On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > dlmarion pushed a commit to branch main in repository
> > https://gitbox.apache.org/repos/asf/accumulo.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> > new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > described below
> >
> > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > Author: Dave Marion <dl...@apache.org>
> > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> >
> > Enable Github wiki in asf.yaml
> > ---
> > .asf.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/.asf.yaml b/.asf.yaml
> > index bc2c943e82..08aa357082 100644
> > --- a/.asf.yaml
> > +++ b/.asf.yaml
> > @@ -27,7 +27,7 @@ github:
> > - big-data
> > - hacktoberfest
> > features:
> > - wiki: false
> > + wiki: true
> > issues: true
> > projects: true
> >
> >
> >
>
[DISCUSS] Enable Github wiki in asf.yaml?
Posted by dl...@comcast.net.
I reverted the change. I didn't think it would be a big deal, but if it requires discussion, then let's discuss it.
I'm looking for a place to host information related to internal design discussions. I envision these to be living documents that will be updated over time as the design/implementation progresses and that other committers will be able to comment on and edit. I don't feel that the website is the correct place for this because:
1. I don't think internal design discussions should go on the project website.
2. Changes to the design documents could not be seen by others right away (IIRC changes to the website are built and available at https://accumulo.staged.apache.org/, but human intervention is required to publish it at https://accumulo.apache.org/).
I looked in the INFRA issues and other projects are using the GH Wiki feature and I saw no mention of backing it up or the requirement to do so (maybe they rely on GitHub backing it up?). It does appear that we would need an INFRA ticket so that they can modify the GitHub project settings to lock the GitHub wiki down so that only committers can modify it. If GitHub Wiki is not acceptable, then I think Apache Confluence (https://cwiki.apache.org) might be an acceptable alternative.
-----Original Message-----
From: Christopher <ct...@apache.org>
Sent: Saturday, February 25, 2023 4:41 AM
To: accumulo-dev <de...@accumulo.apache.org>
Cc: commits@accumulo.apache.org
Subject: Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml
I don't recall a discussion about this change, but I think it goes against previous efforts to make the website the one canonical location for our documentation. I don't even think infra is backing up wiki repos, so there wouldn't even be a record of the wiki contents in ASF spaces (vs. the main repo, which is backed up to GitBox and the issue tracker, which CCs the notifications list).
In short, I think this should be reverted and we should not use the GitHub wiki. If we need to store documents in a version controlled way, we can store them on the website, or in our project's SVN dev space. The wiki is just another place people would have to follow if they want to participate, and I don't think that serves us. Therefore, I think we shouldn't use it.
On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> dlmarion pushed a commit to branch main in repository
> https://gitbox.apache.org/repos/asf/accumulo.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> described below
>
> commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> Author: Dave Marion <dl...@apache.org>
> AuthorDate: Fri Feb 24 15:59:10 2023 -0500
>
> Enable Github wiki in asf.yaml
> ---
> .asf.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index bc2c943e82..08aa357082 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -27,7 +27,7 @@ github:
> - big-data
> - hacktoberfest
> features:
> - wiki: false
> + wiki: true
> issues: true
> projects: true
>
>
>
Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml
Posted by Christopher <ct...@apache.org>.
I don't recall a discussion about this change, but I think it goes against
previous efforts to make the website the one canonical location for our
documentation. I don't even think infra is backing up wiki repos, so there
wouldn't even be a record of the wiki contents in ASF spaces (vs. the main
repo, which is backed up to GitBox and the issue tracker, which CCs the
notifications list).
In short, I think this should be reverted and we should not use the GitHub
wiki. If we need to store documents in a version controlled way, we can
store them on the website, or in our project's SVN dev space. The wiki is
just another place people would have to follow if they want to participate,
and I don't think that serves us. Therefore, I think we shouldn't use it.
On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> dlmarion pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/accumulo.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new ae8a817e7b Enable Github wiki in asf.yaml
> ae8a817e7b is described below
>
> commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> Author: Dave Marion <dl...@apache.org>
> AuthorDate: Fri Feb 24 15:59:10 2023 -0500
>
> Enable Github wiki in asf.yaml
> ---
> .asf.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index bc2c943e82..08aa357082 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -27,7 +27,7 @@ github:
> - big-data
> - hacktoberfest
> features:
> - wiki: false
> + wiki: true
> issues: true
> projects: true
>
>
>
Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml
Posted by Christopher <ct...@apache.org>.
I don't recall a discussion about this change, but I think it goes against
previous efforts to make the website the one canonical location for our
documentation. I don't even think infra is backing up wiki repos, so there
wouldn't even be a record of the wiki contents in ASF spaces (vs. the main
repo, which is backed up to GitBox and the issue tracker, which CCs the
notifications list).
In short, I think this should be reverted and we should not use the GitHub
wiki. If we need to store documents in a version controlled way, we can
store them on the website, or in our project's SVN dev space. The wiki is
just another place people would have to follow if they want to participate,
and I don't think that serves us. Therefore, I think we shouldn't use it.
On Fri, Feb 24, 2023, 15:59 <dl...@apache.org> wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> dlmarion pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/accumulo.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new ae8a817e7b Enable Github wiki in asf.yaml
> ae8a817e7b is described below
>
> commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> Author: Dave Marion <dl...@apache.org>
> AuthorDate: Fri Feb 24 15:59:10 2023 -0500
>
> Enable Github wiki in asf.yaml
> ---
> .asf.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index bc2c943e82..08aa357082 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -27,7 +27,7 @@ github:
> - big-data
> - hacktoberfest
> features:
> - wiki: false
> + wiki: true
> issues: true
> projects: true
>
>
>