Kivy
Replies: 20 comments 64 replies
-
|
In keeping with my idea that there should not be competing channels, how would people feel about these:
|
Beta Was this translation helpful? Give feedback.
-
|
I have voiced my concern about this exact issue. My 2 cents :
That should be the case in my opinion. Question goes into discussion, ideas go to the ideas and actual software bug goes into the issue section. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I have mixed feelings about stackoverflow, let's ignore this point. I do however am strongly against using discord as a support forum. Specially cause of moderators have to respond about same question over and over and over again to different people.
Fair enough.
I don't know about this one. One strong argument against this is, " If the integration is in place, maybe some moderation might see the issue and respond to it" |
Beta Was this translation helpful? Give feedback.
-
|
I think you did a pretty exhaustive list of the current channels.
The current blog is old and unmaintained and needs at least to be replaced. The current content (the one which still makes sense in 2023), could be migrated to the new "blog" area. Need:
I partially disagree with this one. Discord is a safe and trustworthy place, where people can discuss about their issues without "keeping an history". And, even if is public, people seem to be really comfortable sharing their logs and chunks of code, as they know that no one is going to shame them (as sometimes happens on StackOverflow). People can still post on StackOverflow if they want to (and maybe we can encourage it), but IMHO should not be the first option. About Google Support Groups: Would be better to only keep Discord, but we have a pretty community (of people answering to questions), how can we ask them to move to another platform? Need:
Absolutely agree.
We opened Github Discussions as Discord is not crawled by search engines, and we hoped for people moving there to ask for support. But I agree this is useless without someone replying (and closing duplicates).
Absolutely yes. |
Beta Was this translation helpful? Give feedback.
-
|
If you had two 🥇 hero coins to spend, would you spend them on the blog? I mean if a volunteer turns up and says that's what they want to do, then sure, but if we were wishing for more bodies, this isn't where I think we should spend them. Either way, if the old blog is just distracting people into thinking it is a reliable source of Kivy news, let's close it down until someone new is willing to breathe life into it. Close it down just means: put a post saying "Thanks for coming by. This isn't being updated at the moment. Please visit .... for announcements.". It can stay in that state until someone decides to fix it. |
Beta Was this translation helpful? Give feedback.
-
|
I hear you about Discord being a safe-space to post code. What manual FAQ maintenance suffers from is the long tail. It covers 80% of the problems, but having a Google searchable place means someone can find the one other person who got the exact same error message. [That said, I despair at the common conversation format: Person A: I got this message: Morton not throcked error. Is there a compromise?
That's still two channels, but I am hoping the easiest issues will then be tackled by the cheapest labour - other Kivy users - before they drag in Kivy devs. |
Beta Was this translation helpful? Give feedback.
-
|
Great summary (add Google Groups), and IMHO an important question, its clearly a mess.
Strongly agree. As you point out users arrive for many reasons - the one thing they have in common is they don't know what they don't know. This means they are unable to self sort. We see this all the time in GitHub issues that are support questions, and to a lesser extent on Discord. So allowing choices doesn't work. The channel must be strongly threaded and searchable by topic. No need to reinvent the wheel here, the success of Stackwhatever shows us the style that works. Pick one. Its OK to kill stuff, somebody will howl, but in six weeks time nobody will remember. The gain in killing stuff that doesn't work well is huge. But as software creators we overvalue our creations to the rest of the world; we are too attached. We tell ourselves stories why something is important, its just a story we tell ourselves - most of the rest of the world doesn't notice. So its OK to kill stuff. |
Beta Was this translation helpful? Give feedback.
-
Is that different to the Mailing Lists? |
Beta Was this translation helpful? Give feedback.
-
|
The user interaction is primarily with a browser, though email submissions are possible. And separately sending private (not public) emails is possible. As contrasted with say GitHub where user interaction is primarily with a browser, though email alerts are possible. |
Beta Was this translation helpful? Give feedback.
-
|
More edits to the list:
|
Beta Was this translation helpful? Give feedback.
-
|
Stackoverflow is not newbie friendly at all and I dislike it. Discord: I am inclined in making Discord support more organized in general. Although Discord has no SEO, history is not completely lost, because you can use the search bar and at least search for keywords, or paste your error there. You may find some discussion related to your problem. This is exactly what I do when I have problems with Kivy. I don't know how many forums can be created in Discord, but I think we should:
This will solve multiple issues we have in Discord support channels right now: most people use One thing I don't understand about |
Beta Was this translation helpful? Give feedback.
-
Problem with this approach is that not all questions get seen by people with knowledge.
While i like forums. It has the same problem as with discord. No SEO.
it needs time to get indexed by google. |
Beta Was this translation helpful? Give feedback.
-
Well, the |
Beta Was this translation helpful? Give feedback.
-
Fair enough, i would suggest making a tool of sorts to inject discord support channel messages to |
Beta Was this translation helpful? Give feedback.
-
I believe that would be ideal. |
Beta Was this translation helpful? Give feedback.
-
Yayy I am glad that we are on same page :) |
Beta Was this translation helpful? Give feedback.
-
|
FYI Google Groups is now blocked https://groups.google.com/g/kivy-users |
Beta Was this translation helpful? Give feedback.
-
Things like this is exactly why we should re-evaluate our channels. TBH the best solution is see is the |
Beta Was this translation helpful? Give feedback.
-
This is tough for me to address, because I joined StackOverflow over a decade ago, and I wasn't a newbie developer at the time, so I already had some idea about how to ask sensible questions, so the fact I didn't find this isn't a valuable contribution. However, I do remember joining Discord, and omg it was a terrible experience. There are "Servers" that aren't servers. There is Mystery Meat Madness, where you have to hover over random pictures trying to find the group you are looking for. There are notifications that don't actually take you to where someone is talking to you. There is constant spam trying to trick you into upgrading. It seems to require updating every second day. It is a constant stresser. There are emotes that are a foreign language to me. The only way to survive is to mute, mute, mute, mute. So, if you are going to say StackOverflow isn't welcoming, sure, but Discord is no bed of roses either. |
Beta Was this translation helpful? Give feedback.
-
It's StackOverflow
probably referring to this https://github.com/orgs/kivy/discussions/8422#discussioncomment-7410968
I think it's better if we deprecate multiple support channel and move to one unified channel.
Yes and we are planning to move everything to github discussions. Reasons :
I think it's more about repeating questions rather than misuse. For example i posted same question in discord 7 months ago, but got no answer and only today we are having discussion to implement that functionality in kivy. Consequently i visited subreddit, you folks are awesome |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Uh, I don't think we have consensus (or fiat) on that yet. |
Beta Was this translation helpful? Give feedback.
-
|
@Julian-O thanks for the detailed response. There is clearly an element moderation that is required where support questions must be quickly sent to the appropriate channel. I expect novices and the desperate will ask questions on every available channel. There needs to be moderation to guide people to the appropriate channel. Keeping support questions out of the dev forum falls to the dev forum members. Keeping support questions out of github issues is more problematic. Perhaps there should a set of volunteers to do a first level triage of kivy github issues, with the goal of identifying issues and vectoring the users to the appropriate channel. |
Beta Was this translation helpful? Give feedback.
-
👋Hi, I am the current set of volunteers in the Triage team! I just joined. I am mainly focussed on going through the backlog, but I am trying to help with new issues as well. [Relying on one person - especially me! - isn't sustainable, but it's a start.] |
Beta Was this translation helpful? Give feedback.
-
|
Google Groups is gently decaying, if we don't get it back it is not a big loss. Discord is designed for chat, not tech support. The successful design is Stacksomething, or clones of it. Don't try to be smarter than success. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not a discord fan, but it sure seems popular. Why is that? Is there a class of users that prefer that kind of chat interaction? Is it where the experts are answering questions? I'm confident we can transition to any forum as the new "official" forum. Success requires a commitment to answer questions and moderate the forum, and a communication and transition plan to move users from the current official forums to the new forum. I'm not a fan of moving to StackOverflow. The Discord, Kivy User Support, Github discussions, the kivy Discord channel, Reddit, all build a community of users. StackOverflow throws all the users in one big bucket. StackOverflow is also battling it own problems. They just laid of 28% of their staff, and are battling with AI generated solutions. |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to be an apologist for StackOverflow, but the staff layoffs and AI generated solutions seem to be fairly minor nits in this decision. (Discord Inc just layed off 4% of its staff, by comparison.) To me, a far bigger issue is that all the StackOverflow data is licensed for re-use and available for downloading, so if StackOverflow shuts its doors, all the work done answering questions is still available. If Discord shuts its doors, we are scre-... errr... in a business discontinuity situation. Meanwhile you (@ElliotGarbus) made a good point about meeting the community where it is. If we can help across multiple channels, maybe that's a good thing. You also point out that Discord is popular. While I personally am only here because that is where the official site is, I understand Discord is popular. But the [Kivy] tag on StackOverflow is also popular! >13,000 questions, currently being posted at about 2 per day - roughly the same as r/kivy. Huge shout out to StackOverflow user John Anderson who has answered over 2000 questions about Kivy, and @inclement who has recently hit 1000 Kivy-related answer posts. |
Beta Was this translation helpful? Give feedback.
-
|
Another not quite lively information channel is the wiki. https://github.com/kivy/kivy/wiki |
Beta Was this translation helpful? Give feedback.
-
|
Just an FYI. Looking for how some other project manage these channels, I took a look at Flask. They are using discord for questions, and there a good number of support questions in the github issues. The amazing thing is there are no open issues on GitHub. I assume they are focused on getting issues closed. I took a look a Django, they also have a good number of support issues in their issues database. They point them to the support forum. I'll take a look at a few more tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
Good thinking. I was bemused by Flask and checked it out. Support questions are migrated to Git Hub discussions. Issues are sometimes closed within minutes. Closed issues are often pre-emptively locked to prevent any further discussion (including complaints about closure). Users are chastised for posting issues instead of PRs. Bugs are mostly fixed in days/same day! I had to look for a bit to see one that lasted 6 weeks! Seems very strictly policed. [I wonder if there is a phenomena with Flask that the technology is all written in the same language/concepts as the users know, so they are better able to understand and debug their own issues? Where Kivy is built on so many technologies the users know nothing about.]. |
Beta Was this translation helpful? Give feedback.
-
|
I suspect the way issues are closed has less to do with technology and more to do with organization and resources. Taking a look at their web site it is telling that there is a defined role for issue management. https://palletsprojects.com/people/ I'll do some more basic research and reach out to a few folks I know for additional suggestions. After I've done a little more leg work I might reach out to the Flash issue manager and see if he is open to sharing some of their key learnings. There is one improvement we can make to reduce the use of support questions in GItHub issues. We need to update the template for feature requests and blank issues and perhaps remove the ability to open blank issues. If you open a bug request the template includes this text: "The issue tracker is a tool to address bugs only (search known bugs: https://git.io/vM1iE). This message is NOT included in feature requests or blank issue requests. It should be added. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at: https://kivy.org/doc/stable/contact.html Looks like this also needs to be updated - or made consistent: https://github.com/kivy/kivy/wiki#getting-help |
Beta Was this translation helpful? Give feedback.
-
|
I will look into making these consistent. This discussion (what are the right channels) was part of that effort. |
Beta Was this translation helpful? Give feedback.
-
About directing people to the correct channel: The structure might be:
|
Beta Was this translation helpful? Give feedback.
-
|
I'll give people a couple more days to comment, and then I will try to turn our collective thoughts into a proposed plan and a set of instructions. Hopefully that will be helpful to give people something more concrete to get their teeth into and rip apart. |
Beta Was this translation helpful? Give feedback.
-
|
Here is my summary of the key parts of the discussion. [Please let me know if you think I got something wrong.] List of available channelsThe list of channels where one might go to get support as a Kivy user (official and unofficial)
The list of channels where one might go to learn about Kivy:
The list of channels where one might go to discuss development of Kivy itself:
Topics CoveredI am not trying to re-state every single point, but just give a quick overview of what we debated:
Immediate Plans[I tried to keep this next section balanced, but if my personal bias was going to sneak in, here is where it would be, so keep an eye out!] While we didn't have a formal vote or attempt to reach a single consensus, I think the groups' conclusions were: For support:
For learning about Kivy:
For contributors to Kivy development:
Possible future plans
|
Beta Was this translation helpful? Give feedback.
-
|
Focusing on the proposed immediate plans. There are some ambitions ideas here, and I'm not sure there are the resources to bring all of these ideas to reality. We need to weigh these against the problems we are trying to solve. I think you called these out clearly:
Some comments on these statements: Kivy users are asking support questions in the wrong place (naivety or desperation), and getting silence. In any user supported activity this is a risk. Part of the problem is that when users don't get their questions answered, they will go anywhere to find a solution. This is not about wrong channels or right channels. This is an open source project and a community. There is not a paid support tier with an SLA. Users will go where they get answers, We need to be aggressive in pushing support questions out of GitHub Issues and out of the Dev channels. This requires behavioral changes on the part of the Devs, and how issues are managed and closed. A more robust discipline on issue management would be helpful here. The work you are doing @Julian-O , tagging issues is critically important here. The Kivy support team are wasting their time answering repeated questions that could be answers by Google. I'm afraid this is the nature of support. In the old days we used to refer to RTFM (read the "fine" manual) questions that customers would ask. If something is documented, it make it easier to answer the questions, it will not keep users from asking the question. @RobertFlatt has done the community a great service writing the "Unofficial Buildozer Users' Guide", it is a great resource for answering questions. I'm going to be direct, no offense is intended. I think the following ideas are nice, but not of much value nor actionable.
In short the action list becomes:
Do we have sustainable resources and plans to address these key areas:
|
Beta Was this translation helpful? Give feedback.
-
|
I think we are really quite closely aligned here - more than your response might suggest.
This made me pause, because I see maybe 8 hrs work here, and I was planning to do most of it myself (PR reviews and maintaining community consensus being the biggest bottlenecks). Now, I am looking around for the minefield I haven't seen.
😂 😂 Sorry, that certainly isn't the image I was trying to convey. I think we need a word that sits between "promoting" and "documenting", because it is more than just the cover-your-ass "Well, we mentioned this was deprecated on page 75 of the PDF, so you should have known better and it isn't our fault" sense of documenting. It is trying to put the warning on just about every surface the user might touch in order to post a support question.
Agreed. My solution was:
I am proposing one or two sentences in a document, so the effort is minimal. @misl6's proposal for "typeform-like page" fits under possible future plans, and can be negotiated then.
A few sentences under "Contributing" in the documentation. A couple of posts of Discord as described above.
[I worry I have missed your point here. Happy to hear it elaborated] I am certainly not talking monetary bounties :-) Again, I am talking a few sentences here and there. An occasional reminder on the Support and Dev channels. We already have an FAQ ready to be filled with distilled support knowledge. @RobertFlatt has shown us it can be done!
Right. No energy to sustain them. No attempt to ask devs to monitor them. Just a couple of sentences in the docs acknowledging they exist for the people who prefer them to Discord.
I would like to post to it a few times encouraging the experts who monitor it but don't come here to come check out our better channels, and any users who didn't get answer there to try Discord. If closing down further posts or autoreplying to them is an option, that would help prevent the worst case scenario: it becomes as a place for people to post Support Questions, and get zero answers.
That keyword "sustainable" is the hardest one. I don't have an answer for that. I am aggressively tagging and closing old issues on GitHub. I am confident that I will get through them all, but there is always the proverbial bus that strikes down developers who don't have business continuity plans. After that, I expect to keep on top of new issues... for a short while. It won't be forever. I can see the need for some process documents to help others join me and follow me, but ultimately it is a staffing issue. I have some ideas about the PR backlog which I think should be a separate discussion, but the headline versions are: "Reviews by overworked core devs are the bottleneck." and "Find a foster parent for old PRs". |
Beta Was this translation helpful? Give feedback.
-
|
Great discussion guys. As I have said before I don't think you can expect users to self select a channel because they don't know our view of what they need (even if we tell them). And I don't think you can train users to choose a site, in part because it is training an ever changing population; and in part as Elliot pointed out they will go where ever they think they can be heard. Don't expect reason from people who just want to be told how to get out of a hole. If you have documentation, you still have to get people to read it, they want a ladder not a book. |
Beta Was this translation helpful? Give feedback.
-
|
It's not a battle we win; support requests are always going to leak through. It is more an ongoing effort to keep our work areas clean enough to work. It is about making it easier for naive users to go the right way, with wayfinding arrows, and harder to go the wrong way, with closed doors with "Staff only" signs on them. Using Buildozer as an example: It was snowed under: over half the issues needed closing. Under such conditions, the Issue database becomes an unusable liability for devs - a place for hope to die, rather than guidance as to where their efforts are required. I think this justifies making some areas more unwelcoming for lost people, and other places easier to find in comparison. |
Beta Was this translation helpful? Give feedback.
-
Agreed!
Creating something yourself is much more efficient then trying to encourage others. 😊 Not related to what you are proposing but in my experience many of the users looking for support are new to python and kivy. They are not reading documents. They have watched a few YouTube videos and are learning by failing. I suspect this is what inspired @RobertFlatt to write: https://github.com/Android-for-Python/Android-for-Python-Users#confidence-and-competence Thanks for what you are doing here - these efforts will improve the community and ultimately the project. You have my full support! |
Beta Was this translation helpful? Give feedback.
-
|
I plan to propose some edits for the following documents, to make them closer match the positions above (assuming that there aren't major objections to them):
|
Beta Was this translation helpful? Give feedback.
-
|
Re: Development versus Master. The changes to the documentation and the changes to the code have both been submitted to the same branch of Buildozer (i.e. Master). Meanwhile, the official documentation version (https://buildozer.readthedocs.io/en/latest/installation.html) matches the released version (i.e. the one on PyPI) which still talks about installing Cython manually. So, I'm confused by your concern. Have I misunderstood? Re: It has to be done in p4a. Yes. I want it to be done in p4a. Then it can be removed from Buildozer install scripts AND Buildozer documentation - it should have never been in either. I don't fully understand why p4a's dependency story is so complicated that this wasn't fixed there in the first place. All of this is a workaround until p4a can be fixed.
My expectation is that p4a's first change will be remove the current upper bound on Cython version numbers. At that point, either Buildozer 1.11 will still be official, and the documentation will be recommending to manually install an older version of Cython, or Buildozer 1.12 will be official, and the installation scripts will automatically install an older version of Cython. Either way, it shouldn't cause problems. If p4a increases the lower bound to Cython 3.0 or above in one fell swoop, whether (a) before Buildozer 1.12 or (b) after Buildozer 1.12 but before Buildozer 1.13, then we have problems in either case, because Buildozer documentation in 1.11 will tell them to manually install a pre-3 version, or the Buildozer scripts in 1.12 will automatically do it. So, this change doesn't make the problem worse. It makes the software follow the instructions the humans were told to do. I think it makes it better, because it always remembers to follow them, and it is closer every other Python package, installation-wise. |
Beta Was this translation helpful? Give feedback.
-
@Julian-O Of course you're right - I must have been thinking of an old discussion - but the it the docs it appears they are all the same. |
Beta Was this translation helpful? Give feedback.
-
|
There really two issues here 1) is the documentation reliable, 2) how to handle changes in Cython version
You totally miss the point that everybody out there has the release version. All documentation must match the release version. That some but not all documentation matches the release version is not better it is worse! It is clueless to think that new users will distinguish between the two versions of the documentation. Experienced users will generally assume the GitHub one is better because of the latency in the readthedocs version. Except in the case of this error. The documentation is not reliable. At a minimum the current p4a Cython version must be documented in Buildozer dependencies with a dependency on Buildozer 1.15.
I can't speak to your understanding, only your actions.
If you think you don't understand then you should not be making changes.
Making predictions is hard, specially about the future.
In the context of the release version of Buildozer, these versions are just wrong. The paragraph makes no sense.
In the future p4a will always change Cython version, we just don't know how. Any reasoning based on an unreliable assumption will be unreliable.
No, because without updating Buildozer users will have the wrong Cython for the currently released p4a and the build will fail. There is no user visible event that says update Buildozer (nor any reason they should except to work around this update). The current (1.15) design means users do not have to update Buildozer, this is the best case. YOU BROKE THAT. And there seems no reason for the breakage as the implementation just moves the problem, it doesn't fix it. This is not better. Thinking about it, this is really worse as it impacts everybody not just the dweebs who don't read documentation. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @RobertFlatt, I want to have a good working relationship with you. I admire the work you do in the support channels, and the Android For Python guide was very helpful to me. But I wasn't impressed with the tone here. I have tried to adopt a fairly deferential tone here myself, because (a) I expect to mistakes as someone new to the project and doesn't know all the historical complexities, (b) I expect to make mistakes as someone who is human, and (c) because senior developers have egos, and I don't want to step on their toes. However, the risk is that this tone might be wrongly interpreted as weakness, naivety or stupidity on my part. I fear that has triggered this response. I want to reset that dynamic quickly. I disagree that documentation currently under development must match the released version of the product. I have never worked on a project that has taken this approach - when would the documentation get a chance to be updated in such a system? I think my approach is the industry norm, and not "clueless". If people come to the development branch for the latest unreleased documentation, they have to expect it applies to the latest unreleased code. (Some sections might be lagging the code, of course.) The ReadTheDocs stable version should be for the current released product. I noted that there was no link to that given from PyPI - maybe people come to GitHub because they can't find the ReadTheDocs version? I raised an issue to improve that.
This came across as glib, I am afraid. I think you can speak to my understanding to the degree that I had just explained it. "Have I misunderstood?" is me being deferential and open to correction.
This came across as condescending, I am afraid. I did NOT make changes in p4a, partly for this reason. I did make changes in Buildozer ands its documentation where my understanding of the code is much stronger. If we berate people for making changes until they are complete experts of the whole ecosystem, then the project is doomed.
This came across as condescending and non-responsive, I am afraid. We make predictions all the time. I covered all the most likely scenarios.
Ahh! That is fair. So before writing that paragraph I googled "Buildozer documentation", and clicked on the top hit: https://buildozer.readthedocs.io/en/latest/ It said Buildozer was version 0.11, and I based the rest on that without thinking to check further. So please interpret 0.11 as 1.5.0, 0.12 as 1.6.0 (or whatever is planned next), etc. I have raised an issue to correct that. That is likely another reason why user's might be reading Buildozer documents from GitHub.
That is non-responsive. You are implicitly reasoning that telling people to install an old version of Cython in the Buildozer documentation is okay, but that is based on the same assumption.
I assume you mean 1.5.0, and got thrown by me talking about wrong versions. Sorry! I think your disaster scenario is:
This is where the contention seems to be. How are they supposed to know that? Whatever the channel is that tells them that, it still works under the new system. In the meantime, there are so many ways to avoid this worst case disaster, by doing the right thing (supporting more than one major version of Cython, telling PIP about dependencies, co-releasing Buildozer with p4a) that I think the benefits (preventing people from not installing Cython at all) more than justify the risks. |
Beta Was this translation helpful? Give feedback.
-
|
Clearly there is not a snowball in hell's chance that you and I could work together. My choices in such a situation are well known: agree and commit, disagree and commit, or quit. I choose to quit the project. |
Beta Was this translation helpful? Give feedback.
-
|
I reached out to David Lord the maintainer of Flask on Mastodon, looking for advice and key learnings, My Question: I'm impressed to see Flask has zero open issues, and seems to clear issues with amazing speed. Do you have any advice or methods to share in managing the issues and users Here is what he shared: Keep issues about the library itself, have a separate place for questions with using the library.
Have resources to allow the community to help you and grow. This is something I'm actively working on still for Pallets. Have clear instructions for contributors. Not only writing code, but writing docs, triaging issues, finding duplicates, or answering questions. Have clear instructions for maintainers, such as processes and policies they should know about. All the stuff you've figured out, that's in your head, should be in a doc so others don't need to go through the same trials. |
Beta Was this translation helpful? Give feedback.
-
I am kinda against this, it feels like hostile behavior. It's not like Contributing to I am all for removing churns, but please dont become like
This i agree with. |
Beta Was this translation helpful? Give feedback.
-
|
I personally see the "0 issues" target as just a (bad) "marketing" thing. Having "0 issues" does not mean the project is in good shape. Feature requests belong to GitHub issues, and unless these requests are clearly out of the project scope, I do not see why we should close them, even if no one is ready to work on the new feature. Instead, locking issues, even if I agree with @baseplate-admin which may seem hostile, could help to keep us organized. I've seen too much GitHub issues (even closed ones) with useless (in terms of helping to reproduce the issue) comments like:
So, I'm +1 for locking the issues after have been closed, but we SHOULD make it crystal clear that the original author or anyone bumping into a similar issue can (and is encouraged to) open a new issue by adding more context that can help us to reproduce and fix it. |
Beta Was this translation helpful? Give feedback.
-
|
This is the current Kivy "Contact Us" page: https://kivy.org/doc/stable/contact.html Below is my proposed replacement. I will get the RST working properly and a proper PR with a proper review, but this is a sneak peak so all the people who have shown interest can rip it apart. As you read this, please try to imagine "English is my second language. Python is my first programming language. Kivy is my first framework. I am stuck with an error message I don't get, and I need help now!" Will this get you to where you need to go? Also, I plan to hammer home this URL in multiple locations across all the projects, so it isn't just for the Kivy framework, it is for Buildozer, python-for-android, Plyer, etc. etc. When it comes to reviews, my ego is pretty robust. Please don't hold back. .. _contact: Contact UsAre you having trouble using Kivy? Is there an error you don't understand? Are you Before you start, please read our The Please hang around in Discord for an answer. We are mostly based in Europe, so
You might like to check our issue trackers out on GitHub. There is the main There are also independent communities on Other Ways to Contact UsThe Kivy team is built of volunteer developers like you, and we always need more help. If you want to give back to the community, please see our If you would like to help with your wallet or purse instead, we gratefully accept |
Beta Was this translation helpful? Give feedback.
-
|
@misl6 This is a very good idea. I would suggest beyond help, there should be an overview of the kivy projects. I can even recall how I stumbled upon plyer. |
Beta Was this translation helpful? Give feedback.
-
That absolutely makes sense! |
Beta Was this translation helpful? Give feedback.
-
|
My only concern with that suggestion is my competence: I live and breathe Markdown and edit buttons. I can trudge slowly through RST and GitHub. I don't know how to edit the web-site. |
Beta Was this translation helpful? Give feedback.
-
Unless you want to try it out editing the website, if you manage to find the time to write it in Markdown, I can move it on the website, when I'm too tired to read code 😅 (Or, we can likely find someone who can help us on Discord #dev channel) |
Beta Was this translation helpful? Give feedback.
-
|
To maintain momentum, I am going to edit the Kivy RST docs now, so we have the policy in place. Then we can find someone to migrate the same text onto the web-site. [Aside: The kivy/kivy readme has a first cut at introducing "sister" projects.] |
Beta Was this translation helpful? Give feedback.
-
|
FYI: The Kivy User Support Forum on Google Groups is working again. |
Beta Was this translation helpful? Give feedback.
-
|
Nice! So at least, if we decide to sunset the Google Groups channel, we can at least reach out to the community, and send the new links. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the wait, but I've been busy these days ... 😅 @Julian-O , I've seen kivy/kivy#8442 , and I think we could merge it. (and later have that moved into the website). Here is another "clean-up" oppurtunity, and I think is better to split that FAQs into single documents for every sister project. (and then link all the FAQs page from the "Contact-us" website page). @ElliotGarbus are you comfortable switching to another platform (Github Discussions) and slowly sunset the Kivy Google Groups (dev and users) by suggesting the users to ask the same question on Github Discussions when a new one shows up? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Just repeating that back to check I have it.
|
Beta Was this translation helpful? Give feedback.
-
|
Since Github Discussions need to be linked to a repository of the organization, and currently is linked to FYI: I will create I mean, I think we can all trust @ElliotGarbus since it managed the Google Groups for years, but I hope someone else to join @ElliotGarbus in the future to handle the "Github Discussions" moderation, etc ... @Julian-O , just to confirm: What "admin-like" features you have here on this discussion? (I guess you can't edit / delete / lock, which is bad) |
Beta Was this translation helpful? Give feedback.
-
|
I can:
[On Issues, I can assign a person, but Discussions don't have that concept.] I can't:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the directions on custom watch! |
Beta Was this translation helpful? Give feedback.
-
This is a good idea.
A few ideas come to mind as documents to support users, especially new users:
Any other suggestions? |
Beta Was this translation helpful? Give feedback.
-
|
Looks good, you guys seem to be converging on great. Since documentation is also a topic I'd like to renew my offer, from the beginning of this year, of the Unofficial Buildozer Users' Guide. The examples too, but that is perhaps too far off topic. |
Beta Was this translation helpful? Give feedback.
-
|
I heard a rumour that you were happy for the Kivy project to copy sections from your guide into the official documentation. Is this offer the same as the one you are renewing? Much of the guide would (with edits) fit into the Buildozer FAQ, but we'd need a volunteer for that. |
Beta Was this translation helpful? Give feedback.
-
|
Rumors always get scrambled. Good thing you had the presence of mind to check. In the context of this discussion, the offer is the whole Unofficial Users' Guide, and I will delete my copy. With regard to editing, I think its pretty good the way it is so I'm not the right person. For editing support documentation the right person is somebody who is active in support. More generally all (and only) the active support people should have edit permission. They experience the issues, anybody else would be just stating opinion unsupported by experience - and this is all about user experience. Offer was also for the examples, and possibly the packages. Each as a set, no cherry picking. But of course when the project owns any of this it is the project's to do as it decides. |
Beta Was this translation helpful? Give feedback.
-
|
@RobertFlatt: Thanks for the clarification - and the generous offer to the project! While I have Personal Opinions™ on what should happen, this is beyond my paygrade, and this is getting off-topic here. I think a separate discussion should cover this. |
Beta Was this translation helpful? Give feedback.
-
Kivy has multiple competing places for conversations. It isn't clear which are the right ones to use.
I am hoping here to
(1) get a mostly-complete list of those channels, and
(2) get some clarity on which ones are best and/or acceptable for which conversations.
I don't mean for users to have to look here to find out where they should go, but to provide a basis for the documentation and issue-handling guidelines.
Behind this are two big driving forces:
There is a surfeit of support requests from users, and, perhaps in desperation, they are pervasive and lowering signal-to-noise ratios of every dev channel. A lot of them are about not following the manual, a lot more are documented in unofficial guides, a lot of them are simple beginner coding questions where helping them is going to help only one person. However, hidden in the questions are people stumbling over actual bugs that devs should hear about, and hidden in the responses is advice that could help multiple people, if search engines could find them.
There are too many competing channels, where one consolidated channel would be better!
Here is my initial list:
Mailing Lists (Poor SEO. No metrics. History is hard to find.)
Discord Channels (No SEO. No metrics. History is lost.)
Discord Forums (No SEO. No metrics. History is kept.)
Github (SEO is good. Metrics kept. History kept.)
Kivy Blog (SEO is good. Metrics not kept. History kept)
StackOverflow (SEO is good. Metrics not kept. History kept)
What have I missed?
Beta Was this translation helpful? Give feedback.
All reactions