[Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
>- The top priority user story is someone coming to the site and understanding what it is. >- Introductory material is still up for discussion -- making sure the introduction is as effective as possible is (now and always) a very high priority. I'm currently working on *organizing* the material that's currently on the wiki. My work is currently local but if anyone's interested in helping out I can make it available online. I have some thoughts on how we should organize the material, but I'll wait on hashing them out; there are a couple unresolved questions on my mind. >- mray's design opinion: we should not use wiki pages to display > public info pages (for the general visitor community). >- yet, the wiki is primarily intended for stuff that's available to > the general visitor community -- not as engaged as people who have > created accounts, etc. >- Should there be a wiki on the site? >- What form should that wiki take? From this as well as my own work, I'm currently leaning towards NO -- at least not in the form of a traditional wiki. Internal docs can move to OpenProject or Seafile or whatever organizational tools each team is using (or stay on a wiki if that's what the team decides to use). Introductory materials can be moved to normal html web pages. However, I think that to maximize involvement we should have a way for people to submit changes for those web pages; my own first contribution to snowdrift was improving some wording on a wiki page. Given some sources that suggest a wiki may actually discourage participation (because people feel they're not knowledgeable enough and are afraid to overwrite old content), I'm a fan of providing two ways to edit an informational page: 1. Pull request to git.gnu.io, or wherever we end up permanently hosting our site code 2. A "suggest edits" button on each page which functions like a wiki-style edit button, but instead creates a pull request from their edits. That way even those unfamiliar with git can contribute and become involved. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote: > >- The top priority user story is someone coming to the site and > understanding what it is. > >- Introductory material is still up for discussion -- making sure the > introduction is as effective as possible is (now and always) a very > high priority. > > I'm currently working on *organizing* the material that's currently > on the wiki. My work is currently local but if anyone's interested > in helping out I can make it available online. I have some thoughts > on how we should organize the material, but I'll wait on hashing > them out; there are a couple unresolved questions on my mind. This sounds great. Maybe to give yourself space to keep working, but to not feel like you're keeping people "in the dark", want to plan to give a report in X days? A week maybe? > > Given some sources that suggest a wiki may actually discourage > participation (because people feel they're not knowledgeable enough > and are afraid to overwrite old content), I'm a fan of providing two > ways to edit an informational page: > > 1. Pull request to git.gnu.io, or wherever we end up permanently >hosting our site code > 2. A "suggest edits" button on each page which functions like a >wiki-style edit button, but instead creates a pull request from >their edits. That way even those unfamiliar with git can >contribute and become involved. I'll leave it to the design team for final decisions, but this sounds pretty cool to me. I might suggest against creating literal pull requests, though. That would require tossing all the html at the user. In the short term, it might be better to let them have a textentry to describe suggestions in free-form. signature.asc Description: Digital signature ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
On 02/02/2016 09:09 AM, Bryan Richter wrote: > On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote: >>> - The top priority user story is someone coming to the site and >> understanding what it is. >>> - Introductory material is still up for discussion -- making sure the >> introduction is as effective as possible is (now and always) a very >> high priority. >> >> I'm currently working on *organizing* the material that's currently >> on the wiki. My work is currently local but if anyone's interested >> in helping out I can make it available online. I have some thoughts >> on how we should organize the material, but I'll wait on hashing >> them out; there are a couple unresolved questions on my mind. > > This sounds great. Maybe to give yourself space to keep working, but > to not feel like you're keeping people "in the dark", want to plan to > give a report in X days? A week maybe? > >> >> Given some sources that suggest a wiki may actually discourage >> participation (because people feel they're not knowledgeable enough >> and are afraid to overwrite old content), I'm a fan of providing two >> ways to edit an informational page: >> >> 1. Pull request to git.gnu.io, or wherever we end up permanently >>hosting our site code >> 2. A "suggest edits" button on each page which functions like a >>wiki-style edit button, but instead creates a pull request from >>their edits. That way even those unfamiliar with git can >>contribute and become involved. > > I'll leave it to the design team for final decisions, but this sounds > pretty cool to me. I might suggest against creating literal pull > requests, though. That would require tossing all the html at the user. > In the short term, it might be better to let them have a textentry to > describe suggestions in free-form. > I hope to review all this more soon, but the idea of "suggest change" and Git-based changes to pages for participation seem ideal, see this thread: https://snowdrift.coop/p/snow-wiki/w/en/wiki/c/3491 So, again, moving to Gitit would be ideal because it's a wiki backed by Git that uses the same Haskell and Pandoc base as the rest of the site, and we could then have controls about how the wiki edits worked and otherwise have Git control over the content without making this live in the level of compiled hamlet code or something. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote: > > So, again, moving to Gitit would be ideal FWIW I think we should try to avoid talking about implementation details when deciding on design and vision questions. Tech is important to design inasmuch as it sets the boundaries of possibility, but actual tech decisions should only truly follow design decisions. signature.asc Description: Digital signature ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
On 02/02/2016 09:37 AM, Bryan Richter wrote: > On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote: >> >> So, again, moving to Gitit would be ideal > > FWIW I think we should try to avoid talking about implementation > details when deciding on design and vision questions. Tech is > important to design inasmuch as it sets the boundaries of possibility, > but actual tech decisions should only truly follow design decisions. > Okay, the design proposal I'm asking for here is that we indeed have a Git-backed wiki as integrated in the site as we can. My concern in this case is that I think to avoid extra formalities, and the practical existence of the Gitit codebase, I'm pushing toward actually accepting the pros/cons/limitations of Gitit for now. In other words, I want the decision to be that we work with what's available realistically and go with that and adapt it. So, let's not discuss further here, the issue is to make decisions via the new process of user stories and sorting priorities in OpenProject. That said, I think sometimes there's value in saying, "let's not spend time designing our optimal process, let's use Gitit as an existing base and just make the most of it." because sometimes we need to accept a path that works and go forward rather than deliberate on every case. And this is one where I'm proposing a specific path because it seems practical enough and adaptable to the overall design vision, even if that's not totally finalized. Still, I know that even that path will go better when we understand the priorities more clearly. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
On February 2, 2016 12:09:02 PM EST, Bryan Richter wrote: >On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote: >> >- The top priority user story is someone coming to the site and >> understanding what it is. >> >- Introductory material is still up for discussion -- making sure >the >> introduction is as effective as possible is (now and always) a very >> high priority. >> >> I'm currently working on *organizing* the material that's currently >> on the wiki. My work is currently local but if anyone's interested >> in helping out I can make it available online. I have some thoughts >> on how we should organize the material, but I'll wait on hashing >> them out; there are a couple unresolved questions on my mind. > >This sounds great. Maybe to give yourself space to keep working, but >to not feel like you're keeping people "in the dark", want to plan to >give a report in X days? A week maybe? I should be at a reasonable pause point today or tomorrow; I'll send out an email then. >> >> Given some sources that suggest a wiki may actually discourage >> participation (because people feel they're not knowledgeable enough >> and are afraid to overwrite old content), I'm a fan of providing two >> ways to edit an informational page: >> >> 1. Pull request to git.gnu.io, or wherever we end up permanently >>hosting our site code >> 2. A "suggest edits" button on each page which functions like a >>wiki-style edit button, but instead creates a pull request from >>their edits. That way even those unfamiliar with git can >>contribute and become involved. > >I'll leave it to the design team for final decisions, but this sounds >pretty cool to me. I might suggest against creating literal pull >requests, though. That would require tossing all the html at the user. >In the short term, it might be better to let them have a textentry to >describe suggestions in free-form. If the backend is markdown, I think that would be ok to show the user. The interface I would propose would be near-identical to how wikis work right now, except change the 'save' button to 'submit change request', etc. It allows people who don't yet understand git to submit change requests. If needed, we could add a written note informing a user that if they don't know how to make the changes themselves they can simply write their suggestion in the comment field.___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting
On February 2, 2016 12:48:18 PM EST, Aaron Wolf wrote: >On 02/02/2016 09:37 AM, Bryan Richter wrote: >> On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote: >>> >>> So, again, moving to Gitit would be ideal >> >> FWIW I think we should try to avoid talking about implementation >> details when deciding on design and vision questions. Tech is >> important to design inasmuch as it sets the boundaries of >possibility, >> but actual tech decisions should only truly follow design decisions. >> > >Okay, the design proposal I'm asking for here is that we indeed have a >Git-backed wiki as integrated in the site as we can. This is only a decision to make if we decide a wiki is the best form for this information. >My concern in this case is that I think to avoid extra formalities, and >the practical existence of the Gitit codebase, I'm pushing toward >actually accepting the pros/cons/limitations of Gitit for now. In other >words, I want the decision to be that we work with what's available >realistically and go with that and adapt it. > >So, let's not discuss further here, the issue is to make decisions via >the new process of user stories and sorting priorities in OpenProject. >That said, I think sometimes there's value in saying, "let's not spend >time designing our optimal process, let's use Gitit as an existing base >and just make the most of it." because sometimes we need to accept a >path that works and go forward rather than deliberate on every case. >And >this is one where I'm proposing a specific path because it seems >practical enough and adaptable to the overall design vision, even if >that's not totally finalized. Still, I know that even that path will go >better when we understand the priorities more clearly. I agree, let's table the discussion for the moment. I also agree it seems reasonable that we would end up using Gitit in some form or another. We can figure out the details when we have a better idea of what we want from the system, from the user story work in OpenProject. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design